Miesiąc: lipiec 2024

https://chacker.pl/

Najpierw zbudujemy podstawowe laboratorium do wyszukiwania zagrożeń na Twoim hoście lokalnym lub w chmurze.

Warunki wstępne

Ponownie  użyjemy czcigodnego DetectionLab autorstwa Chrisa Longa (clong), rozszerzonego o HELK i Mordor autorstwa Roberto Rodrigueza (Cyb3rWard0g). Warunki wstępne są następujące:

• Obsługiwane są systemy Windows, Linux, macOS, Azure i AWS.
• Ponad 55 GB wolnego miejsca na dysku.
• Zdecydowanie zalecane jest co najmniej 16 GB pamięci RAM.
• Włóczęga 2.2.9+.
• Packer 1.6.0+ (wymagany tylko w przypadku budowania własnych pudełek).
• VirtualBox 6.0+ (starsze wersje mogą działać, ale nie są testowane).
• Zarejestrowana wersja VMware (działają tylko zarejestrowane wersje).

Wymagane jest dodatkowe oprogramowanie; Więcej informacji można znaleźć na stronie DetectionLab.

https://chacker.pl/

Dostępnych jest kilka metod tworzenia własnego laboratorium wykrywania zagrożeń. Można na przykład ręcznie skonfigurować wszystko, czego potrzebujesz do wyszukiwania zagrożeń, w tym serwery domen, stacje robocze i narzędzia bezpieczeństwa. Temu tematowi można by poświęcić całą książkę, zatem aby dyskusja była krótka, skupimy się na zastosowaniu metod zautomatyzowanych. Mimo to, jak zobaczysz, wciąż musimy zakasać rękawy i dostosować zautomatyzowane laboratoria. Jeśli chodzi o laboratoria automatycznego wyszukiwania zagrożeń, dwa projekty są mocno wspierane i warte uwagi: DetectionLab i HELK. Po pierwsze, DetectionLab1, stworzony przez Chrisa Longa (clong), jest dobrze wspierany przez kilku programistów i oferuje najszerszy wybór narzędzi i zautomatyzowane opcje instalacji na hoście lokalnym, za pośrednictwem kilku systemów operacyjnych i w chmurze. Po drugie, projekt HELK2 wraz z powiązanymi projektami, takimi jak Mordor, OSSEM i The ThreatHunter-Playbook, cieszy się dużym poparciem braci Rodriguez (Roberto i Jose) oraz wielu innych twórców (Open Threat Research Forge) i jest warte rozważenia i wykorzystania. Główna różnica między tymi dwoma projektami polega na tym, że DetectionLab to kompletne środowisko laboratoryjne ze wszystkimi wymaganymi narzędziami, ale koncentruje się na Splunk. Z drugiej strony HELK nie jest kompletnym środowiskiem laboratoryjnym. Zamiast tego jest to platforma analityczna (oparta na Elasticsearch7 i narzędziach), która może rozszerzyć istniejące środowisko laboratoryjne. Jeśli jednak szukasz największej elastyczności i możliwości instalacji lokalnej, powinieneś skorzystać z DetectionLab. Na koniec warto wspomnieć o wielu innych zautomatyzowanych laboratoriach, ale są one mniej obsługiwane, więc mogą występować problemy, które nie zostaną rozwiązane.

https://chacker.pl/

Polowanie na zagrożenia to proces ręczny, który wymaga poznania procesów, aktorów zagrażających i TTP. Co ważniejsze, aby rozwinąć umiejętności łowieckie, wymagana jest praktyka. W tym rozdziale skupimy się na konfiguracji laboratorium.

https://chacker.pl/

Co to jest laboratorium polowania na zagrożenia? Polowanie na zagrożenia zostanie omówione w następnym rozdziale, ale zasadniczo jest to systematyczne polowanie na zagrożenia, które w innym przypadku nie byłyby widoczne w sieci, za pomocą technologii takich jak SIEM, IDS, IPS i tak dalej. Aby nauczyć się tego niezbędnego zestawu umiejętności, będziesz potrzebować bezpiecznego środowiska do gry — środowiska laboratoryjnego z zainstalowanymi wszystkimi wymaganymi narzędziami, w ramach zautomatyzowanego wdrożenia, które można szybko skonfigurować i zdemontować. W tym celu przeanalizujemy najnowsze i najlepsze opcje laboratorium wykrywania zagrożeń.

https://chacker.pl/

Programy dowodzenia i kontroli oraz programy uruchamiające kod powłoki to dwa kluczowe narzędzia, z którymi muszą się zapoznać zespoły czerwone i etyczni hakerzy. Produkty C2 pozwalają na zdalną kontrolę hosta, a także łatwiejsze wykonywanie zadań poeksploatacyjnych. Programy uruchamiające pomagają nam wprowadzić naszych agentów C2 do systemów. Zrozumienie tego, a także tego, jak zbudować silne profile unikania sieci i ominąć EDR i AV w systemie, może pomóc nam zainstalować nasze narzędzia w systemach i zapobiec ich wykryciu i złagodzeniu. Im dłużej przebywamy w systemie bez wykrycia, tym większa szansa, że ​​nasze zadania zakończą się sukcesem.

https://chacker.pl/

Niektóre rozwiązania EDR można wyłączyć lub wyłączyć. Inne mają funkcję zapobiegania manipulacji, która uniemożliwia zatrzymanie usług i odmowę pozwolenia na odinstalowanie lub zamknięcie usług. Jest to zazwyczaj część konfiguracji, dlatego każdy profil używany w produkcie może mieć inne ustawienia ochrony przed manipulacją. Testowanie, czy można wyłączyć te usługi, może wywołać alerty, ale może również zakończyć się sukcesem. Ponadto wiele nowszych technologii wymaga raportowania do chmury w celu monitorowania i uruchamiania alertów. Konfigurując reguły zapory sieciowej oparte na hoście, dodając wpisy do pliku hosts, modyfikując lokalne wpisy DNS i nie tylko, możesz zakłócić tę komunikację. To zakłócenie umożliwi Ci znalezienie sposobów na wyłączenie narzędzia bez konieczności raportowania Twoich działań do usługi monitorującej. Ponadto niektóre produkty mogą mieć usunięte sterowniki ze środowiska Windows, co jeszcze bardziej ogranicza widoczność. Niezależnie od tego, z jakim rozwiązaniem EDR masz do czynienia, najlepiej sprofiluj maszynę, na której się znajdujesz, zanim podejmiesz ryzykowne zachowanie. Ponieważ te produkty cały czas się zmieniają, jeśli nie jesteś zaznajomiony z systemem, przeprowadź badania na temat tego systemu, aby określić obejście rejestrowania, metody wyłączania i opcje dezinstalacji przed rozpoczęciem działań po eksploitacji w systemie.

https://chacker.pl/

Wykrywanie i reagowanie na punkty końcowe (EDR) staje się coraz bardziej powszechne w środowiskach korporacyjnych. EDR zazwyczaj przygląda się zachowaniu plików binarnych w systemie, oprzyrządowując procesy za pomocą podłączonych interfejsów API, dzięki czemu może obserwować różne zachowania i oceniać, czy są one ryzykowne. Różne produkty łączą interfejsy API na różne sposoby, ale różnią się one również w każdym wdrożeniu. Ustawienia i wyjątki stosowane w każdej organizacji mogą się różnić. Dodatkowo zabezpieczenia samego rozwiązania EDR mogą być inne. Większość rozwiązań EDR posiada zarówno tryb detekcji, jak i blokowania. W zależności od stanu EDR Twoje testy mogą zostać zablokowane lub nie, nawet jeśli mają charakter ostrzegawczy.

https://chacker.pl/

Systemy C2 często umożliwiają szablony komunikacji. Ponieważ HTTP jest najpopularniejszym protokołem komunikacji C2, ważne jest, aby podczas tworzenia szablonów komunikacji wiedzieć, gdzie najlepiej umieścić dane. Szablony określają lokalizacje, w których dane będą umieszczane podczas wysyłania i odbierania danych za pomocą systemu C2. Na przykład wiele systemów C2 umożliwia uruchomienie żądania GET dotyczącego meldowania się i pobierania poleceń, a także żądania POST w celu odesłania danych z powrotem. Przykładowe żądanie GET może wyglądać następująco:

Widzimy tutaj, że identyfikator serwera C2 może być zawarty w linii URI. Byłoby to łatwe do zobaczenia i dopasowania różnych zaangażowanych gospodarzy. Chociaż ta prosta formuła jest powszechna, lepiej byłoby umieścić wartości w pliku cookie. Pliki cookie nie są rejestrowane na wszystkich serwerach proxy i nie są pierwszą rzeczą, na którą ludzie patrzą w raportach, dlatego też wymagają dodatkowego kopania, aby je zobaczyć. Do wysyłania danych wiele osób korzysta z żądań POST, ponieważ dane znajdują się w ładunku. Sposób przedstawienia tych danych może wymagać przemyślenia. Bardzo prosty profil może wyglądać następująco:

Chociaż jest to podstawowa kwestia, większość krytycznych danych znajduje się w treści żądania POST, co oznacza, że ​​prawdopodobnie nie zostaną one nigdzie zarejestrowane. Ponieważ to jest zakodowane w standardzie base64, można go łatwo zdekodować za pomocą automatycznych narzędzi. Wybór lepszego schematu kodowania i szyfrowanie danych może utrudnić dekodowanie. Ponadto dopasowanie klienta użytkownika do domyślnej przeglądarki użytkownika, a następnie użycie podobnych nagłówków sprawi, że będzie wyglądać bardziej normalnie. Ponieważ ten szablon jest tak prosty, oczywiste jest, że jest to ruch C2. Jeśli jednak sprawisz, że żądania GET i POST będą wyglądać tak, jakby korzystały z interfejsu API REST lub innego rodzaju rzeczywistego ruchu HTTP, oprócz wybrania lepszych nagłówków i klienta użytkownika, możesz jeszcze lepiej to połączyć. Ogólnie rzecz biorąc, wybranie realistycznie wyglądającego profilu, a następnie użycie tych samych nagłówków, których używa zwykły użytkownik systemu, zwiększy szansę na uniknięcie wykrycia.

https://chacker.pl/

Oprócz szyfrowania niektóre protokoły zapewniają lepszą analizę niż inne. Protokoły takie jak HTTP są dobrze rozumiane i mają wiele procedur obsługi, które je rozumieją. Inne protokoły mogą mieć inne kryteria inspekcji, a mieszanie protokołów dla pojedynczego systemu C2 może pomóc w dalszym dezorientowaniu obrońców. Na przykład DNS to kolejny powszechny protokół, ponieważ wiele organizacji nie ma dobrego monitorowania ani analiz DNS. Jednak DNS jest niezwykle zaszumiony, więc może być lepiej stosowany do sprawdzania i sygnalizowania niż do wysyłania dużych ilości danych. Połączenie DNS z innym protokołem, takim jak protokół strumieniowania w czasie rzeczywistym (RTSP) lub WebSockets, będzie oznaczać, że trzeba będzie przeanalizować wiele punktów danych, aby uzyskać pełny obraz tego, co robi Twój system C2. Używając profili wykorzystujących metodę okrężną dla nazw hostów, możemy spowodować, że obrońcy będą musieli również znaleźć wszystkie nazwy hostów używane przez zaatakowany system, aby poznać częstotliwość i wielkość ruchu opuszczającego organizację. Wybór dobrze udokumentowanych protokołów, dla których urządzenia sieciowe mogą mieć procedury obsługi, jeszcze bardziej zwiększy Twoje szanse na sukces. Kontrole obwodowe mogą przepuszczać tylko ruch, który rozumieją, więc użycie całkowicie niestandardowego protokołu C2 może zostać zablokowane, ponieważ w urządzeniach sieciowych nie ma programów obsługi, które poradziłyby sobie z tym konkretnym typem ruchu.

https://chacker.pl/

W przypadku uchylania się od C2 powszechne są dwa typy szyfrowania. Pierwszym z nich jest unikanie oparte na TLS. Korzystając z protokołu TLS, obszary, które nie korzystają z inspekcji TLS, nie będą mogły zajrzeć do wnętrza ruchu, dlatego jedynymi narzędziami do wglądu w ruch będzie częstotliwość komunikacji i miejsca docelowe. Jeśli to możliwe, użycie szyfrowania TLS pomoże chronić integralność ruchu C2 i ukryć strukturę i treść komunikacji przed obrońcami. W przypadku jakichkolwiek wątpliwości dotyczących obecności inspekcji TLS zaleca się użycie szyfrowania w samym protokole C2. W zależności od komunikacji nie całą zawartość można zaszyfrować (na przykład w przypadku protokołu HTTP nagłówki nie mogą być szyfrowane). Jednakże treść treści i obszary takie jak pliki cookie mogą być szyfrowane. Szyfrowanie tych danych oznacza, że ​​nawet w przypadku przechwycenia protokołu TLS treść przesyłanych tam i z powrotem w systemie C2 nie jest od razu przejrzysta, a określenie, jakie działania podejmuje system C2, jest trudniejsze do określenia. Wybierając szyfrowanie, upewnij się, że wybierasz dobrze znane schematy szyfrowania, a nie coś podstawowego, jak szyfrowanie oparte na XOR, ponieważ niektóre schematy szyfrowania, takie jak XOR, mogą być podatne na ataki ze znanym tekstem jawnym. Rzeczy takie jak nazwa hosta prawie zawsze pojawiają się w pierwszej części transakcji. Wybierając lepszy schemat szyfrowania, taki jak AES lub RC4, zapewniasz znacznie większe bezpieczeństwo danych i utrudniasz manipulowanie lub wykrywanie ruchu bez posiadania naszego prawdziwego kodu powłoki.