Autor: admin

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.

https://chacker.pl/

Po ustanowieniu kanału C2 musimy być w stanie uniknąć wykrycia w sieci. Istnieją dwa obszary kontroli, których zazwyczaj musimy unikać. Pierwszy to IDS/IPS, a drugi to wykrywanie proxy. Większość organizacji nie odszyfrowuje danych TLS wewnętrznie, ale mogą odszyfrować dane TLS wychodzące poza organizację. Wiedząc o tym, mamy wiele obszarów, w których można zastosować szyfrowanie i unikanie zabezpieczeń.

 

https://chacker.pl/

W laboratorium Nim będziemy używać tej samej konfiguracji, co w poprzednich dwóch laboratoriach, z naszym modułem obsługi Metasploit Meterpreter nasłuchującym i budującym nasz kod na maszynie Kali. Aby skonfigurować nasze moduły dla naszego kodu Nim, musimy zainstalować moduł. Nimble jest menedżerem modułów Nimble, więc z naszego katalogu Shells instalujemy moduł winim za pomocą Nimble, w następujący sposób:

Pakiet winim zawiera moduły systemu Windows i definicje potrzebne do uruchomienia naszego kodu powłoki. Nie jest instalowany domyślnie, więc musimy go zainstalować. Następnie rzucimy okiem na nasz kod Nim w pliku nim.template w katalogu powłoki. Ten kod jest oparty na wielu przykładach OffensiveNim autorstwa Byt3bl33der. Wyeliminujemy wiele sprawdzania błędów i przesyłania wiadomości, aby zaoszczędzić miejsce:

Funkcja Patchntdll zastępuje funkcjonalność funkcji EtwEventWrite kodem powrotu, dzięki czemu nie wykona żadnego zawartego w niej kodu. Funkcja EtwEventWrite rejestruje zdarzenia Event Tracing for Windows (ETW), więc zapobiegnie zapisaniu żadnego z nich, ukrywając w ten sposób nasz kod przed jakąkolwiek instrumentacją, która go używa. Aby to zrobić, zaczynamy od uzyskania informacji o funkcji, dzięki czemu wiemy, co musimy nadpisać. Funkcja LoadLib (1) ładuje bibliotekę ntdll.dll do naszego kodu. Funkcja symAddr (2) pobiera adres funkcji EtwEventWrite. Funkcja VirtualProtect (3) ustawia lokalizację pamięci, którą nadpisujemy, na Odczyt/Zapis/Wykonanie, abyśmy mogli (4) zastosować nadpisane bajty do tej pamięci. Na koniec przywracamy pierwotny tryb ochrony do pamięci zapisanej w zmiennej origProtect za pomocą funkcji VirtualProtect (5) . Po wyłączeniu ETW musimy wstrzyknąć nasz kod powłoki. Aby to zrobić, użyjemy funkcji injectCreateRemoteThread do wstrzyknięcia naszego kodu powłoki w nowy proces:

Część tego kodu widzieliśmy już wcześniej, a wzór wygląda znajomo. W tym przykładzie uruchamiamy nowy proces (1) (w tym przypadku notepad.exe), w którym wstrzykniemy nasz kod. Musimy zawiesić proces, aby nie był widoczny i nie dawał użytkownikowi kontroli. Zamiast tego otworzymy nasz proces (2), abyśmy mogli nim manipulować i zapisać w nim nasz kod powłoki (3). Resetujemy (4) ustawienia ochrony pamięci, aby nie wyglądała dziwnie, a następnie tworzymy (5) wątek. Wątek będzie nadal działał, a nasz kod powłoki zostanie wykonany, podczas gdy normalna funkcjonalność procesu będzie nadal zawieszona i niewidoczna dla użytkownika. Na koniec musimy powiązać te informacje w jedną całość. Robimy to w odpowiedniku funkcji main dla Nim:

Oznacza to, że jeśli nie dołączymy tego kodu jako biblioteki, a jest to główny moduł projektu, to załata bibliotekę DLL, a następnie wstrzyknie kod powłoki. Możemy zbudować kod powłoki za pomocą polecenia build_nim.sh. Plik binarny /tmp/nim_dropper64.exe powinien teraz znajdować się w katalogu /tmp, a kiedy uruchomimy go w systemie Windows, nie powinniśmy zobaczyć żadnych wyników, ale powinniśmy zobaczyć powrót sesji w Metasploit:

https://chacker.pl/

Nim to kolejny skompilowany język, który obsługuje wiele systemów operacyjnych i wykorzystuje niektóre popularne części Pythona i innych języków, aby stworzyć bardziej przyjazny dla użytkownika język, który kompiluje się do C, C++, Objective-C i JavaScript. Dzięki temu kod można skompilować do jednego z języków pośrednich i włączyć do innych projektów, a także sam skompilować do formatu binarnego. Elastyczność Nim jest częścią jego popularności, podobnie jak fakt, że sygnatury plików binarnych będą na tyle różne, aby ominąć wiele tradycyjnych wykryć AV. Obecnie nie ma zbyt wielu repozytoriów korzystających z Nim, ale przyciągnęło to uwagę zarówno podmiotów zagrażających, jak i etycznych hakerów. Jedną z osób, która przeprowadziła świetne badania na temat ofensywnego Nima, jest Marcello Salvati, znany w Internecie jako Byt3bl33der. Jego repozytorium Offensive Nim pod adresem https://github.com/byt3bl33d3r/OffensiveNim zawiera próbki implementacji wielu technik uruchamiania i unikania kodu powłoki.

https://chacker.pl/

Pliki binarne systemu Windows w Go można skompilować krzyżowo z Kali Linux przy użyciu pakietów mingw. Po zainstalowaniu pakietów golang i mingw wystarczy, że określimy architekturę i system operacyjny, a Go zajmie się za nas większością instrukcji kompilacji. W tym laboratorium będziemy nadal używać naszego detektora Meterpretera i będziemy używać plików build_go.sh i go.template w katalogu Shells. Kod Go w tym laboratorium wykorzystuje nieco inną technikę niż w poprzednim laboratorium. Zamiast wątków używamy światłowodu do uruchomienia naszego kodu. Włókno jest podobne do nici. Jest to strumień wykonania oddzielony od głównej części kodu. Jednak wątki są planowane przez aplikację. Dwa wątki nie muszą robić nic specjalnego, aby oba działały w tym samym czasie. Światłowody wymagają harmonogramu do obsługi wielozadaniowości. W rezultacie, kiedy uruchomimy nasze włókno, będzie ono działać aż do zakończenia działania lub do chwili, gdy nasz kod zrzeknie się kontroli nad resztą aplikacji. Ponieważ nasz kod powłoki nie wie, że znajduje się we włóknie, efektem końcowym jest to, że nasz kod będzie zawieszony do momentu zakończenia działania kodu powłoki. Kod Go będzie wyglądał podobnie do tego, co zrobiliśmy w C#, ponieważ używa również bibliotek Windows kernel32.dll i ntdll.dll. Kod ten jest modyfikowany na podstawie przykładów światłowodów ired.team, a także kodu z repozytorium Ne0nd0g wspomnianego wcześniej. W tym przykładzie będziemy kodować nasz kod powłoki w base64, co pozwala nam łatwo umieścić go w składni Go:

Tutaj używamy biblioteki base64 i dekodujemy ciąg znaków, który ustawiliśmy za pomocą naszego kodu powłoki, sc i zapisujemy go w zmiennej kodu powłoki. Jeśli zwrócone zostaną jakiekolwiek kody błędów, zostaną one zapisane w zmiennej err. Operator := służy do jednoczesnego tworzenia i przypisywania zmiennych, gdzie = służy do przypisania wartości już utworzonej zmiennej:

Aby wykonać nasz kod powłoki, musimy wykonać kilka kroków. Pierwszym krokiem jest przekształcenie naszej głównej nici w włókno. Robimy to za pomocą funkcji ConvertThreadToFiber (1) , która, jeśli zostanie określona bez opcji, pobiera bieżący wątek i konwertuje go na włókno. Musimy to zrobić, ponieważ tylko włókna mogą tworzyć dodatkowe włókna. Następnym krokiem jest przydzielenie pamięci dla naszego kodu powłoki za pomocą funkcji VirtualAlloc (2). Tutaj tworzymy pamięć jako Odczyt/Zapis/Wykonanie w jednym kroku. Może to być postrzegane jako szkodliwe dla niektórych produktów obronnych, dlatego zawsze możemy umożliwić zapis, kopiując kod powłoki, a następnie usuwając bity zapisu za pomocą programu VirtualProtect, aby wyglądało to mniej podejrzanie. Teraz, gdy mamy już pamięć, możemy skopiować do niej kod powłoki za pomocą wywołania RtlCopyMemory (3). Jedną z rzeczy, na które warto zwrócić uwagę w przypadku Go, jest to, że stara się chronić Cię przed niektórymi konwersjami typów, które mogą być niebezpieczne, więc użycie niebezpiecznej biblioteki ominie te zabezpieczenia. Następnym krokiem jest utworzenie nowego włókna do harmonogramowania za pomocą funkcji CreateFiber (4). Zauważ, że na potrzeby tego wywołania tworzymy nowe włókno wskazujące lokalizację pamięci naszego kodu powłoki, które zwraca adres nowego włókna. Mając ten adres możemy ustawić wykonanie na nowym włóknie za pomocą wywołania SwitchToFiber (5). Od tego momentu nasz kod będzie wykonywany aż do zakończenia światłowodu lub kodu z powrotem do głównego włókna. Teraz, gdy rozumiemy, co robi nasz kod, możemy uruchomić skrypt build_go.sh z katalogu powłoki w naszym hostowanym Kali. Spowoduje to utworzenie pliku /tmp/CreateFiber.exe, który możemy uruchomić z naszego okna Windows. Linia kompilacji samego pliku binarnego Go określa architekturę i system operacyjny w wierszu poleceń ze zmienną środowiskową, którą można ustawić w środowisku użytkownika lub w samym wierszu poleceń:

Teraz, gdy działa nasz słuchacz msfconsole, możemy uruchomić kod w systemie Windows:

W naszej sesji Linux Meterpreter powinniśmy teraz zobaczyć nową sesję, z którą możemy wchodzić w interakcję i używać jej do wykonywania poleceń:

Nasz plik binarny w systemie Windows będzie nadal wykonywany, dopóki nie wyjdziemy z sesji Meterpretera, a następnie powinien zakończyć się. Możesz sprawdzić dodatkowe przykłady w katalogu go-shellcode w swojej instancji Kali i możesz spróbować zmodyfikować inne przykłady, aby działały również w polu docelowym.