Windows ma własne narzędzia do ataku. Jak hakerzy wykorzystują zaufane komponenty systemu
Windows 11 posiada setki wbudowanych komponentów, które zostały zaprojektowane do administracji, diagnostyki, automatyzacji i zarządzania systemem. Problem zaczyna się wtedy, gdy te same mechanizmy wykorzystuje atakujący. Nie musi instalować klasycznego malware, jeśli system sam dostarcza mu narzędzia potrzebne do wykonania kolejnych etapów ataku.
To właśnie dlatego współczesne ataki na Windows coraz częściej wykorzystują tak zwane LOLBins — Living-off-the-Land Binaries. Są to legalne, podpisane lub natywne komponenty systemu, które mogą zostać użyte w sposób zgodny z ich normalnym przeznaczeniem, ale w kontekście ataku stają się elementem łańcucha kompromitacji.
To zmienia sposób, w jaki trzeba patrzeć na bezpieczeństwo Windows.
Nie wystarczy już pytanie:
„Czy na komputerze jest malware?”
Znacznie ważniejsze staje się:
„Co robią legalne komponenty systemu i dlaczego zostały uruchomione?”
Trusted tools mogą stać się częścią ataku
Administrator potrzebuje PowerShella. Potrzebuje Windows Management Instrumentation. Potrzebuje narzędzi systemowych, usług, harmonogramu zadań i mechanizmów instalacji.
Atakujący również.
I właśnie dlatego klasyczny model detekcji oparty wyłącznie na rozpoznawaniu podejrzanych plików zaczyna mieć ograniczenia.
Jeżeli napastnik pobierze plik malware.exe, jego obecność może zostać wykryta przez mechanizmy bezpieczeństwa.
Jeżeli jednak wykorzysta istniejący komponent Windows do wykonania określonej operacji, sytuacja wygląda zupełnie inaczej.
Nie pojawia się nowy program.
Nie musi pojawić się podejrzany sterownik.
Nie musi nawet zostać zapisany klasyczny payload.
Atak może zostać zbudowany z elementów, które administrator sam uznaje za zaufane.
PowerShell jako przykład
PowerShell jest jednym z najbardziej znanych przykładów.
Jest legalnym narzędziem administracyjnym i dla administratorów Windows stanowi podstawowy element automatyzacji.
Może zarządzać usługami, procesami, użytkownikami, rejestrem, siecią, konfiguracją systemu i praktycznie każdym istotnym komponentem Windows.
Dlatego jego całkowite wyłączenie nie zawsze ma sens.
Problemem jest nie samo istnienie PowerShella.
Problemem jest kontekst jego użycia.
Administrator uruchamiający PowerShell w celu sprawdzenia konfiguracji serwera nie zachowuje się tak samo jak proces Office, który niespodziewanie uruchamia PowerShell, a następnie wykonuje serię operacji związanych z siecią, plikami i mechanizmami systemowymi.
To właśnie kontekst powinien być podstawą detekcji.
WMI — kolejna warstwa
Windows Management Instrumentation również nie został zaprojektowany jako narzędzie ofensywne.
Wręcz przeciwnie.
WMI służy do zarządzania systemami Windows, zbierania informacji i automatyzacji administracyjnej.
Jednocześnie zapewnia dostęp do bardzo dużej liczby informacji i operacji wykonywanych w systemie.
Jeżeli konto użytkownika zostanie przejęte, dostęp do mechanizmów administracyjnych może zostać wykorzystany jako kolejny krok ataku.
W praktyce oznacza to, że monitoring powinien obejmować nie tylko proces końcowy, ale również łańcuch procesów.
Przykładowo:
Word → PowerShell → WMI → proces systemowy
może być znacznie bardziej interesującym zdarzeniem niż samo uruchomienie PowerShella.
Niebezpieczny jest łańcuch, nie pojedyncze narzędzie
To jedna z najważniejszych zmian w myśleniu o bezpieczeństwie Windows.
Pojedynczy komponent może być całkowicie legalny.
Drugi również.
Trzeci również.
Ale połączone w odpowiedniej kolejności mogą stworzyć skuteczny mechanizm ataku.
Przykładowy schemat może wyglądać następująco:
phishing → przejęcie procesu użytkownika → PowerShell → mechanizm systemowy → persistence → eskalacja uprawnień
Każdy element osobno może wyglądać niepozornie.
Całość już nie.
Dlatego rozwiązania EDR/XDR coraz częściej analizują zachowanie procesów, relacje rodzic-dziecko, dostęp do pamięci, operacje na plikach, komunikację sieciową oraz zmiany konfiguracji.
Windows nie może ufać samemu faktowi, że komponent jest podpisany
Podpis cyfrowy odpowiada przede wszystkim na pytanie:
kto wydał plik i czy jego zawartość została zmodyfikowana?
Nie odpowiada na pytanie:
czy ten konkretny proces powinien wykonywać tę operację w tym momencie?
To fundamentalna różnica.
Legalny komponent może zostać uruchomiony przez złośliwy proces.
Może zostać wykorzystany w nietypowym kontekście.
Może zostać użyty jako jeden z etapów większego łańcucha.
Dlatego „Microsoft signed” nie powinno automatycznie oznaczać „bezpieczne zachowanie”.
Użytkownik nie musi być administratorem
Jeszcze ważniejszy jest fakt, że pierwszy etap ataku często nie wymaga uprawnień administratora.
Atakujący może rozpocząć od zwykłego konta użytkownika.
Dopiero później szuka sposobu na zwiększenie swoich możliwości.
To właśnie dlatego granica:
standard user → administrator → SYSTEM
jest tak istotna.
Współczesny Windows posiada wiele mechanizmów mających utrudniać takie przejście, ale bezpieczeństwo zależy od całego łańcucha.
Na ten temat warto zobaczyć również analizę:
Od zwykłego użytkownika do SYSTEM. Gdzie naprawdę kończą się granice bezpieczeństwa Windows 11?
Dlaczego monitoring procesów jest ważniejszy niż lista aplikacji
Klasyczna administracja często wyglądała mniej więcej tak:
mam antywirusa,
mam firewall,
mam aktualizacje,
mam listę aplikacji,
mam politykę haseł.
To nadal ma znaczenie.
Ale nie wystarcza.
Nowoczesny monitoring powinien analizować między innymi:
kto uruchomił proces,
jaki proces był jego rodzicem,
jakie argumenty przekazano,
jakie pliki zostały otwarte,
jakie procesy zostały utworzone,
z jakimi adresami IP nastąpiła komunikacja,
jakie mechanizmy systemowe zostały wykorzystane,
czy doszło do zmiany uprawnień,
czy utworzono persistence,
czy zachowanie jest typowe dla danego użytkownika i aplikacji.
To już nie jest proste „antywirus znalazł plik”.
To analiza zachowania.
Atak może wyglądać jak administracja
I właśnie to jest największym problemem.
Jeżeli administrator regularnie korzysta z PowerShella, WMI, Task Scheduler czy innych komponentów systemowych, samo ich użycie nie powinno generować automatycznie alarmu najwyższego poziomu.
Atakujący może więc próbować wtopić się w normalną aktywność administracyjną.
Dlatego liczy się:
kto + co + kiedy + skąd + w jakim kontekście
a nie tylko:
jaki program został uruchomiony.
Jak administrator może ograniczyć ryzyko?
Pierwszym krokiem powinno być ograniczenie niepotrzebnych uprawnień.
Jeżeli użytkownik nie potrzebuje administratora, nie powinien go mieć.
Jeżeli aplikacja nie potrzebuje dostępu do określonego zasobu, nie powinna go otrzymywać.
Jeżeli PowerShell jest potrzebny tylko wybranym grupom, warto odpowiednio kontrolować jego użycie.
Kolejna warstwa to logging.
Warto monitorować między innymi:
PowerShell,
procesy tworzone przez aplikacje biurowe,
WMI,
Scheduled Tasks,
usługi,
zmiany w rejestrze,
nowe konta,
zmiany grup lokalnych,
nietypowe połączenia sieciowe,
procesy uruchamiane z katalogów tymczasowych.
Windows może być „czysty” i nadal być zaatakowany
To bardzo ważna konkluzja.
Brak wykrytego pliku malware nie oznacza automatycznie, że system jest bezpieczny.
Atak może wykorzystywać legalne mechanizmy systemowe.
Dlatego analiza bezpieczeństwa Windows musi przesunąć się z pytania:
„Czy znaleźliśmy złośliwy plik?”
na:
„Czy zachowanie systemu odpowiada temu, czego powinniśmy się spodziewać?”
To dużo trudniejszy problem.
Ale właśnie tam znajduje się obecnie duża część realnej walki z atakami.
Jeżeli interesuje Cię szerszy problem zaufania do komponentów Windows, warto również przeczytać:
Twój Windows może być czysty. To nie znaczy, że komputer jest bezpieczny
Podsumowanie
Windows nie jest bezpieczny dlatego, że posiada dużo wbudowanych mechanizmów ochronnych.
Jest bezpieczny wtedy, gdy te mechanizmy są odpowiednio skonfigurowane, monitorowane i ograniczone.
PowerShell nie jest malware.
WMI nie jest malware.
Task Scheduler nie jest malware.
Usługi Windows nie są malware.
Problem zaczyna się wtedy, gdy legalne komponenty zostają połączone w łańcuch działania, którego system nie powinien wykonywać.
Dlatego nowoczesne bezpieczeństwo Windows powinno analizować zachowanie, a nie tylko tożsamość programu.
Atakujący nie zawsze potrzebuje własnego narzędzia.
Czasami wystarczy mu to, co już znajduje się w systemie.
#Cybersecurity #InfoSec #CVE #Vulnerability #Security #CyberAttack #Exploit #Malware #Ransomware
