PowerShell, PsExec i RDP: jak EDR odróżnia działania administratora od ataku?
PowerShell uruchamia się w Twoim środowisku kilkadziesiąt razy dziennie. PsExec jest standardowym narzędziem w arsenale niejednego administratora. RDP to podstawa zdalnej pracy na serwerach.
Te same trzy narzędzia figurują jednak na szczycie list najczęściej wykorzystywanych wektorów w cyberatakach. Są skutecznie, ponieważ są powszechne i domyślnie nikt nie traktuje ich jako zagrożenia.
Pytanie „PowerShell w firmie – jak rozpoznać atak?” nie ma prostej odpowiedzi w formule „jeśli X, to zagrożenie”. Odpowiedź wymaga głębszej analizy. Artykuł pokazuje, jak taka analiza wygląda w praktyce, krok po kroku, na przykładzie narzędzi, które administratorzy i analitycy widzą w konsoli EDR najczęściej.
Dlaczego legalne narzędzie nie jest automatycznie zagrożeniem?
Technika ataku, w której napastnik wykorzystuje natywne, zaufane narzędzia systemu operacyjnego zamiast własnego złośliwego oprogramowania, ma swoją nazwę – Living Off The Land. Logika stojąca za tym podejściem jest prosta. PowerShell, PsExec czy klient RDP są podpisane cyfrowo, obecne domyślnie w środowisku Windows, akceptowane przez większość polityk bezpieczeństwa i używane na co dzień przez administratorów. Zamiast dostarczać własny plik wykonywalny, który może zostać rozpoznany przez sygnaturę antywirusową, atakujący korzysta z narzędzia, które i tak już tam jest, a które to system od razu traktuje jako zaufane.
Pytanie o legalne narzędzia używane przez cyberprzestępców nie brzmi „czy to narzędzie jest niebezpieczne”, bo odpowiedź zawsze brzmi „zależy”. ESET Inspect rejestruje uruchomienie PowerShella tak samo, niezależnie od tego, czy zrobił to administrator wykonujący rutynową konserwację, czy atakujący, który właśnie uzyskał dostęp do stacji roboczej. Sam fakt uruchomienia narzędzia jest tylko punktem wyjścia do analizy, a nie jej wynikiem.
Przykład z organizacji: księgowa uruchamia PowerShell po raz pierwszy, a proces łączy się z zewnętrznym serwerem. Samo użycie narzędzia nie przesądza o ataku, ale w połączeniu z resztą kontekstu (o którym za chwilę), nabiera zupełnie innego znaczenia niż to samo polecenie wykonane przez administratora na serwerze aplikacyjnym.
Jakie znaczenie ma konto użytkownika?
Analityk patrzący na detekcję związaną z ESET Inspect PowerShell, zdaje sobie pytanie:
Kto wykonał tę operację i czy mieści się ona w profilu zachowań tego konta?
Konto administratora systemów, które uruchamia PowerShell kilkanaście razy dziennie w ramach standardowych zadań, ma zupełnie inny profil bazowy niż konto z działu sprzedaży, które nigdy wcześniej nie miało powodu korzystać z tego narzędzia. To samo polecenie, uruchomione przez te dwa konta, niesie różną wagę. Nie dlatego, że jedno konto jest „bardziej zaufane”, ale dlatego, że odstępstwo od typowego wzorca zachowania jest samo w sobie sygnałem, niezależnie od tego, czy konkretna komenda wygląda neutralnie.
Liczy się również poziom uprawnień konta i to, czy dane działanie jest zgodne z jego rolą. Konto serwisowe używane do ściśle zdefiniowanej funkcji, które nagle wykonuje operacje spoza tego zakresu to sygnał, który wymaga wyjaśnienia.
Jak analizować godzinę, urządzenie i historię aktywności?
Nietypowe logowanie RDP jest przykładem tego, jak wiele znaczy kontekst czasowy i lokalizacja w odróżnieniu normalnej aktywności od czegoś, co wymaga dalszej analizy.
ESET Inspect może pokazać nocne logowanie RDP, ale to kontekst pozwala ustalić, czy był to zaplanowany serwis, czy użycie przejętego konta. Analityk powinien sprawdzić kilka wymiarów jednocześnie:
- Czy to konto kiedykolwiek wcześniej logowało się przez RDP na to urządzenie?
- Godzina logowania mieści się w typowym oknie aktywności tego użytkownika lub zaplanowanych oknach serwisowych?
- Adres źródłowy połączenia jest zgodny z wcześniej obserwowanymi lokalizacjami?
- Urządzenie docelowe w ogóle powinno być dostępne przez RDP dla tego konta?
Pojedynczo żaden z tych elementów nie jest rozstrzygający. Administrator czasem faktycznie loguje się poza standardowymi godzinami, żeby wykonać pilną poprawkę. Ale logowanie o nietypowej porze, z nowej lokalizacji, przez konto, które nigdy wcześniej nie korzystało z tej usługi na tym urządzeniu to już trzy niezależne odstępstwa nakładające się na siebie. Ta kumulacja, a nie pojedynczy parametr, przesuwa ocenę zdarzenia z „prawdopodobnie normalne” w stronę „wymaga dalszego sprawdzenia”.
Dlaczego pojedynczy alert nie wystarcza?
Żaden pojedynczy alert, rozpatrywany w oderwaniu od pozostałych, nie daje wystarczających podstaw do jednoznacznej decyzji.
System detekcyjny reaguje na wzorzec. To często konkretne:
- polecenie,
- proces,
- połączenie.
Tylko, że sam wzorzec nie niesie informacji o intencji ani o tym, co wydarzyło się przed i po. Reakcja wyłącznie na pojedynczy alert prowadzi najczęściej jednego z dwóch błędów.
Na coś, co w pełnym kontekście okazuje się rutynową operacją (kosztuje to czas i może niepotrzebnie zakłócić działanie systemu produkcyjnego).
Czegoś, co w oderwaniu wygląda niegroźnie, ale w połączeniu z innymi zdarzeniami układa się w spójny, niepokojący wzorzec.
Dlatego analiza nigdy nie kończy się na przeczytaniu treści jednego powiadomienia. Analityk zawsze “cofa się w czasie” i sprawdza, co działo się na tym koncie i tym urządzeniu wcześniej, oraz czeka lub aktywnie sprawdza, co dzieje się później – zanim podejmie ostateczną decyzję.
Jak sekwencja zdarzeń może wskazywać na rekonesans lub ruch boczny?
Opisany przebieg to złożenie typowych wzorców obserwowanych w środowiskach korporacyjnych. Nie stanowi opisu konkretnego, pojedynczego incydentu, ale pokazuje, jak wygląda analiza sekwencyjna w praktyce.
Punkt wyjścia: na stacji roboczej pracownika działu marketingu otwarto załącznik z wiadomości e-mail. Kilka sekund później uruchamia się PowerShell. To konto, które wcześniej nigdy z tego narzędzia nie korzystało. Proces pobiera dodatkowy kod z zewnętrznego adresu. Pierwsza detekcja, sama w sobie jest niejednoznaczna. Mogła to być legalna, choć nietypowa operacja.
Kilkanaście minut później to samo konto, a właściwie proces działający w jego kontekście próbuje uzyskać dostęp do pamięci procesu LSASS (mechanizmu odpowiedzialnego za przechowywanie danych uwierzytelniających w systemie Windows). To już drugi sygnał, tym razem odpowiadający wzorcowi typowemu dla prób pozyskania poświadczeń innych kont z tego samego urządzenia.
Następnie na sąsiednim serwerze plików pojawia się aktywność PsExec – polecenie zdalnego wykonania, zainicjowane z konta, które przed chwilą było przedmiotem prawdopodobnej próby pozyskania poświadczeń. PsExec sam w sobie jest narzędziem administracyjnym, używanym rutynowo do zdalnego zarządzania.
Ale użycie go z konta, które kilkanaście minut wcześniej nie miało powodu do żadnej aktywności technicznej, w celu uruchomienia poleceń na kolejnym urządzeniu, odpowiada wzorcowi ruchu bocznego. Konkretniej – próbie rozprzestrzenienia dostępu z jednej skompromitowanej maszyny na kolejne w tej samej sieci.
Rozpatrywane tych zdarzeń jako sekwencja:
- Nietypowe uruchomienie PowerShella
- Próba dostępu do LSASS
- Użycie PsExec do innego urządzenia z tego samego konta
Układa się w spójny wzorzec. Początkowy dostęp, próba eskalacji przez pozyskanie poświadczeń, ruch boczny. To właśnie różnica między patrzeniem na alerty pojedynczo, a analizą pełnego przebiegu zdarzenia.
Jeśli wydaje Ci się, że ten problem Ciebie nie dotyczy, odsyłamy do analizy przygotowanej przez CERT Polska. Zespół ten pokazał niedawno, jak łatwo może dojść do całkowicie nieświadomego wykorzystania narzędzia cmd – które, podobnie jak PowerShell, jest domyślnie wbudowane w system Windows.
Szczegóły tego zagrożenia znajdziesz TUTAJ.
Kiedy analityk eskaluje zdarzenie, a kiedy je zamyka?
Decyzja o zamknięciu zdarzenia albo jego eskalacji nie jest kwestią przeczucia. Opiera się na tym, czy dostępny kontekst wystarcza do jednoznacznego wyjaśnienia obserwowanej aktywności.
Zdarzenie zostaje zamknięte, gdy analiza konta, urządzenia, historii i sekwencji działań prowadzi do spójnego, możliwego do zweryfikowania wyjaśnienia. Administrator faktycznie wykonywał zaplanowaną konserwację, proces jest częścią znanego, zatwierdzonego skryptu, a kolejne działania są zgodne z tym, czego można się spodziewać po tej operacji. Takie zamknięcie jest dokumentowane – nie po to, żeby „coś odhaczyć”, ale żeby ta sama sytuacja w przyszłości mogła zostać rozpoznana szybciej, jeśli się powtórzy w tym samym kontekście.
Zdarzenie jest eskalowane, gdy któryś z elementów analizy pozostaje niewyjaśniony albo gdy sekwencja działań odpowiada rozpoznawalnemu wzorcowi ryzyka – takiemu jak ten opisany wyżej. Nietypowe uruchomienie narzędzia, próba dostępu do poświadczeń, ruch w kierunku kolejnego urządzenia. W takiej sytuacji decyzja o dalszym działaniu, na przykład izolacji urządzenia powinna uwzględniać nie tylko prawdopodobieństwo ataku, ale też potencjalny wpływ tej reakcji na ciągłość pracy organizacji.
W modelu, w którym reakcje mieszczą się w uzgodnionym wcześniej zakresie, sytuacje nietypowe lub o niejednoznacznym wpływie biznesowym trafiają do wyznaczonego przedstawiciela klienta. Decyzja o działaniach z realnym wpływem operacyjnym nie zapada w oderwaniu od wiedzy o tym, jak krytyczny jest dany system dla bieżącej pracy organizacji.
FAQ - najczęstsze pytania dotyczące wykrywania ataków i analizy zdarzeń EDR
Dlaczego cyberprzestępcy używają w atakach legalnych narzędzi takich jak PowerShell czy PsExec?
Atakujący wykorzystują wbudowane, zaufane narzędzia systemowe, aby uniknąć wykrycia przez tradycyjne programy antywirusowe. Jest to technika znana jako Living Off The Land (LOTL). Zamiast instalować złośliwy kod, haker używa programów, które domyślnie znajdują się w systemach Windows w każdej polskiej firmie, dzięki czemu początkowa faza ataku wygląda jak rutynowa praca administratora.
Jak system EDR (np. ESET Inspect) odróżnia działanie administratora od ataku hakera?
System EDR ocenia pełny kontekst i profil zachowań konta, a nie tylko sam fakt uruchomienia narzędzia. Użycie PowerShella przez administratora IT to standard. Jednak uruchomienie tego samego narzędzia przez konto pracownika z działu księgowości (które nigdy wcześniej go nie używało), połączone z próbą komunikacji z zewnętrznym serwerem, to potężne odstępstwo od normy i sygnał do natychmiastowej reakcji.
Po czym poznać, że logowanie RDP to atak, a nie zwykła praca zdalna?
System EDR ocenia pełny kontekst i profil zachowań konta, a nie tylko sam fakt uruchomienia narzędzia. Użycie PowerShella przez administratora IT to standard. Jednak uruchomienie tego samego narzędzia przez konto pracownika z działu księgowości (które nigdy wcześniej go nie używało), połączone z próbą komunikacji z zewnętrznym serwerem, to potężne odstępstwo od normy i sygnał do natychmiastowej reakcji.
Na czym polega analiza sekwencji w cyberbezpieczeństwie (wykrywanie ruchu bocznego)?
Analiza sekwencji polega na łączeniu pojedynczych, często niejednoznacznych zdarzeń w spójny łańcuch ataku. Przykładowo: samo pobranie kodu, próba dostępu do poświadczeń (proces LSASS) lub użycie PsExec w oderwaniu mogą być fałszywymi alarmami. Jednak gdy te trzy zdarzenia następują po sobie na jednym koncie w krótkim czasie, jednoznacznie wskazują na tzw. ruch boczny (lateral movement) – czyli próbę rozprzestrzenienia się hakera po firmowej sieci.
Kiedy analityk bezpieczeństwa zamyka alert, a kiedy eskaluje incydent?
Alert jest zamykany (i odpowiednio dokumentowany), gdy analiza potwierdza legalność i kontekst działania, np. zaplanowane prace konserwacyjne. Eskalacja następuje, gdy aktywność pozostaje niewyjaśniona lub pasuje do wzorca ataku. W polskim modelu MDR Perceptus ewentualna decyzja o ostatecznej izolacji urządzenia zawsze uwzględnia to, jak bardzo krytyczny jest dany system dla ciągłości biznesowej Twojej organizacji.
Jeśli zastanawiasz się, czy Twój zespół ma czas i doświadczenie, żeby przeprowadzić dokładnie taką analizę za każdym razem, gdy w konsoli pojawia się podobna detekcja, to dobre pytanie na początek rozmowy o tym, jak wygląda dziś kwalifikacja zdarzeń w Twojej organizacji.
Skontaktuj się z nami
Nasz specjalista odezwie się do Ciebie najpóźniej kolejnego dnia roboczego. Nie musisz wypełniać pola wiadomości, ale krótka informacja o interesującym Cię temacie rozmowy będzie dla nas cenną wskazówką.
