Wykorzystanie Elastic SIEM do wykrywania ataków z użyciem USB
część I – proof of concept
W dzisiejszych czasach zagrożenia cybernetyczne są coraz bardziej zaawansowane i różnorodne, a jednym z nich są ataki z użyciem urządzeń USB. Jednym z takich urządzeń, które może być wykorzystane w atakach, jest Rubber Ducky. Rubber Ducky, czasem będę ją nazywać „kaczuszką”, na pozór wygląda jak zwykły pendrive, ale w rzeczywistości jest świetnym gadżetem służącym do przeprowadzania automatycznych ataków na systemy komputerowe, wykorzystywanym przez pentesterów czy zespoły red team. Przez swoją łatwość użycia oraz zdolność do infekowania systemów w sposób prawie niewykrywalny, Rubber Ducky stanowi poważne zagrożenie dla bezpieczeństwa komputerowego.

Rysunek 1. Zdjęcie pochodzi ze strony shop.hak5.org
W artykule, która rozpocznie serię ciekawych (mam nadzieję ?) treści o cyberbezpieczeństwie skupię się na zastosowaniu Elastic SIEM w celu wykrywania i monitorowania ataków z użyciem w/w kaczuszki. Omówione zostaną następujące zagadnienia:
- Charakterystyka Rubber Ducky
- Praktyczne przykłady użycia Elastic SIEM w kontekście identyfikacji i monitorowania ataków związanych z Rubber Ducky
- Rekomendacje dotyczące zabezpieczenia infrastruktury
W teście pomoże mi Elastic SIEM będącym narzędziem, z którego korzystamy na co dzień świadcząc usługi SOC dla klientów. W przypadku ataków z użyciem Rubber Ducky, Elastic SIEM może zbierać dane z różnych źródeł, wykrywać anomalie oraz analizować nietypowe wzorce zachowań w systemie. Dzięki integracji z innymi narzędziami (firewalle, NAC, antywirusy, EDR-y itd.) czy możliwości automatyzacji, Elastic SIEM może skutecznie pomóc w identyfikacji i monitorowaniu ataków wykorzystujących tzw. bad USB.
[br]

Rysunek 2. Zdjęcie pochodzi ze strony elastic.co
Charakterystyka Rubber Ducky
Za 80 dolarów możemy wyposażyć się w pendrive, który w rzeczywistości jest… klawiaturą. Skrypt zawiera instrukcje mogące obejmować różne rodzaje ataków lub modyfikacje systemowe. Ponieważ kaczuszka działa na poziomie klawiatury (nie jest wykrywane jako oprogramowanie), może wykonywać polecenia z uprawnieniami użytkownika co sprawia, że jego działanie jest trudne do wykrycia. Za dodatkowe 40 dolarów można wyposażyć się w „programator” umożliwiający pisanie instrukcji i poleceń dla urządzenia, które mogą wykonywać różnorodne akcje, takie jak otwieranie programów, wpisywanie danych, symulowanie kliknięć myszy czy wykonywanie poleceń w terminalu.
[br]
Praktyczne przykłady użycia Elastic SIEM w kontekście identyfikacji i monitorowania ataków związanych z Rubber Ducky
W artykule wykorzystam kilka popularnych skryptów, są to kolejno:
- Wyłączenie Windows Defendera
- Kradzież haseł z przeglądarki
- Reverse shell
[br]
Wyłączenie Windows Defendera
Po co to robić? Brak przeszkadzacza pozwoli mi na wykonanie ostatniego skryptu, o którym za chwilę. Przyjrzyjmy się na chwilę zaszytemu skryptowi:
DELAY 1000
REM Open Windows Defender settings
CTRL ESC
DELAY 1000
STRING Windows Security
DELAY 100
ENTER
REM Navigate to realtime protection and disable it
DELAY 500
ENTER
DELAY 500
TAB
DELAY 250
TAB
DELAY 250
TAB
DELAY 250
TAB
ENTER
DELAY 500
SPACE
DELAY 500
LEFT
DELAY 500
ENTER
REM Close Settings
DELAY 500
ALT F4
Ten i wiele innych skryptów można pobrać z Githuba producenta i samemu przetestować.
Chciałem sprawić, że wprowadzane sekwencje będą widoczne na poniższej demonstracji, stąd pojawia się komenda DELAY. Opóźnienie można ustawić na niższe, ale jego brak lub sekwencja w stylu DELAY 100 (czyli 100 milisekund) nie będzie działać, bowiem Windows potrzebuje trochę czasu np. na wczytanie animacji przy przechodzeniu między oknami.
[br]
[br]
Kradzież haseł z przeglądarki
Kaczuszka może wykorzystać skrypty do kradzieży różnych haseł, np. Wifi czy tych przechowywanych w przeglądarkach internetowych – jeśli ofiara nie ma włączonego MFA, pozwoli to na dostęp do różnych kont. Zademonstruję jak to może wyglądać:
[br]
[br]
Pobrany został, a następnie wykonany skrypt w Pythonie, który wykracza poza możliwości Rubber Ducky, ale to właśnie on był inicjalnym wektorem ataku. Hasła można przesłać na zewnątrz – mały plik tekstowy, o ile nie ma restrykcyjnych reguł DLP, raczej nie będzie wykryty przez systemy zapobiegające wyciekom danych:
[br]
[br]
Reverse shell
Skrypt ten pozwoli na zdalne połączenie się z systemem „zarządzającym”, tzw. Command and control. Umożliwi to na zdalne sterowanie komputerem, wykonanie dowolnych poleceń czy nawet instalację dodatkowego oprogramowania. „One is none” i tak samo jest w tym przypadku – zyskamy dodatkowy wektor ataku i nie zostaniemy z niczym po wyjęciu USB.
W tym przypadku ciężko będzie pokazać to na komputerze ofiary, bowiem nawet stosując komendę DELAY będzie widać jedynie wprowadzany skrypt w PowerShellu:
[br]
[br]
Całość trwa jakieś dwie, trzy sekundy. W tym przypadku pobraliśmy plik shell.ps1, gdzie zakres działań już wykracza poza możliwości Rubber Ducky. Zadaniem skryptu jest uruchomienie Netcat i nasłuchiwanie na konkretnym porcie.
Teoretycznie, zarówno nasłuchiwanie Netcatem, jak i otwarcie podejrzanego skryptu w PowerShellu mogłoby zostać wykryte przez antywirusa, ale… właśnie po to został wyłączony w pierwszym kroku.
W jaki sposób ominąłem polityki uruchamiania skryptów w PowerShellu? Jeśli ktoś zna odpowiedź na to pytanie to proszę napisać na kontakt@netxp.pl – dla pierwszego wygranego przewidziana skromna nagroda :)
Nawiązana sesja command and control pozwoli na wykonanie właściwie dowolnych rzeczy. Na komputer ofiary pobrany zostanie plik encryption.exe:
[br]
[br]
Zawartość została napisana w języku Go. Jego działanie polega na zaszyfrowaniu plików znajdujących się w folderze, w którym aktualnie się znajdujemy – nie stoi nic jednak na przeszkodzie, aby to zrobić dla całego dysku C:
[br]
[br]
Pierwszą część mamy z głowy – Rubber Ducky działa.
SIEM’a zasilimy danymi z oprogramowania zainstalowanego na komputerze ofiary, konkretnie jest to Elastic Agent. Elastic Agent posiada funkcjonalności EDR’a, zbiera więc wiele różnych rodzajów danych takich jak logi aplikacji, metryki systemowe czy dane związane z bezpieczeństwem – są to np. próby logowania brute force, wyłączenie antywirusa czy długo utrzymywana sesja z konkretnym adresem IP.
Ważnym aspektem Elastic Agenta jest jego, no cóż… elastyczność. Wszystkie moduły są łatwo konfigurowalne, co umożliwia zbieranie danych z różnych źródeł i przesyłanie ich do centralnego serwera SIEM w jednolitym formacie. Oprogramowanie jest zainstalowane na każdym komputerze które ma być monitorowane, a następnie jest skonfigurowane tak, aby zbierać dane zgodnie z potrzebami organizacji.
[br]

Rysunek 3. Zdjęcie pochodzi ze strony elastic.co
Elastic SIEM może pokazać wiele informacji, a poniżej jeden z widoków na podsumowanie aktywności hosta:
[br]
[br]
Widzimy podstawowe informacje o komputerze ofiary takie jak adres IP, nazwa komputera, lecz najciekawsze informacje znajdziemy na dole – są to host risk score i host risk clasification. Na podstawie zebranych danych SIEM ocenił, że aktywność tego hosta jest bardzo podejrzana i wymaga weryfikacji.
Przejdźmy zatem do alertów, które Elastic SIEM wykrył w trakcie naszego PoC’a.
Windows Defender może być wyłączony na różne sposoby, np. poprzez edycję wpisu w rejestrze lub w PowerShellu. Można to też zrobić przez Windows Security Center – dlatego większość antywirusów czy EDR’ów nie wykryje tego uważając to za intencjonalne zachowanie użytkownika. W innym artykule opiszę pozostałe metody wpływania na Defendera czy ogólnie na oprogramowanie antywirusowe.
Na poniższym obrazku widać 9 alertów pochodzących z hosta LAP42 świadczących o tym, że rzeczywiście Windows Defender został wyłączony.
[br]
[br]
Kolejną rzeczą jest wykrycie ataku z drugiego scenariusza. SIEM powinien monitorować wszystkie podejrzane aktywności związane z uruchamianiem skryptów w PowerShellu, w tym skrypty pythonowe czy pliki wykonywalne .exe lub .msi. W trakcie śledztwa wyszło, że rzeczywiście taki skrypt został uruchomiony, o czym świadczy pole process.args.
[br]
[br]
Dodatkowo można zauważyć biorące udział procesy:
[br]
[br]
W innym artykule chciałbym pokazać możliwości wychwytywania nietypowego ruchu sieciowego za pomocą netflowa i AI – pomogłoby to w znalezieniu informacji czy pozyskane hasła mogły być już gdzieś przesłane.
Pora na ostatni scenariusz, czyli komunikację command and control. Przede wszystkim zwrócę uwagę na alert „Suspicious PowerShell Execution”.
[br]
[br]
Warto zwrócić uwagę na pole event.process.args, gdzie mamy wykonanie bardzo podejrzanego procesu shell.ps1.
[br]
[br]
Osobne dwa alerty wskazują na pobranie pliku za pomocą PowerShella:
[br]
[br]
Wygenerowanych zostanie jeszcze co najmniej kilka alertów.
Przydatną rzeczą podczas dalszej inwestygacji jest możliwość wyizolowania hosta tak, aby nie miał dostępu do sieci. Dzięki temu zabezpieczamy się przed prawdopodobieństwem eskalacji uprawnień czy rozesłaniem potencjalnego ransomware’u po całej sieci.
[br]
[br]
Rekomendacje dotyczące zabezpieczenia infrastruktury
- Edukacja użytkowników – przede wszystkim użytkownicy powinni być świadomi zagrożeń związanych z podpinaniem nieznanych urządzeń.
- Podejście „least privileges” czyli zasada minimalnych uprawnień – im mniej uprawnień ma użytkownik, tym mniej szkód można wyrządzić. Właściwie moje skrypty zdałyby się na nic, gdyby potencjalna ofiara nie miała uprawnień lokalnego administratora.
W naszym Security Operations Center (SOC) wykorzystujemy Elastic SIEM jako jedno z kluczowych narzędzi do monitorowania i analizy zdarzeń związanych z bezpieczeństwem. Dzięki doświadczonemu zespołowi analityków bezpieczeństwa oraz nowoczesnym technologiom, nasz SOC jest w stanie identyfikować i reagować na ataki, takie jak te wykorzystujące Rubber Ducky.
W kolejnym artykule chciałbym podjąć się tematu wykrywania ataków phishingowych i tego, jak Elastic SIEM może w tym pomóc. Będzie to na pewno ciekawe doświadczenie biorąc pod uwagę, że phishing wciąż jest jednym z najbardziej poważnych wektorów ataków, a ten udany potrafi zadać bardzo duże szkody.
Kończąc, chciałbym zaprosić na stronę poświęconemu net.soc, czyli naszej usłudze Security Operations Center o której wspomniałem na początku – https://networkexpert.pl/cyberbezpieczenstwo/security-operations-center/. Jeśli są Państwo zainteresowani usługą lub chcieliby Państwo dowiedzieć się więcej na temat sposobów ochrony przed atakami (i to nie tylko przed kaczuszką ?), serdecznie zapraszam do kontaktu z nami.
[br]
Demo, wdrożenie testowe?
Chętnie pokażemy w detalach jak działa nasze środowisko:
- Demonstracja na naszym systemie testowym
- Wdrożenie testowe (ograniczone czasowo)
Autorem wpisu jest
Michał Zadruski – inżynier sieci i bezpieczeństwa, który w IT swoje pierwsze doświadczenia zdobywał w helpdesku. W Network Expert odpowiedzialny jest za utrzymanie sieci klienta i rozwiązywanie problemów. Swoją wiedzę rozszerza w kierunku rozwiązań Enterprise oraz cyberbezpieczeństwa, którego jest pasjonatem. Posiadacz certyfikatów CEH (Certified Ethical Hacker), CCNA Routing & Switching, CCNP Enterprise oraz Cisco CyberOps Associate.

Szukasz rozwiązania dla swojej firmy?
Napisz do nas!
Specjaliści Network Expert
Cyberbezpieczeństwo
To również może Cię zainteresować:
Od samego początku naszej działalności stawialiśmy na profesjonalne podejście do naszych Klientów
Network w liczbach