Miesiąc: czerwiec 2025

https://chacker.pl/

Jak zapewne zauważyłeś, usługa Azure Active Directory jest integralną częścią wewnętrznego działania usługi Azure. Ważne jest zrozumienie, w jaki sposób system jest zaprojektowany, aby kolejne laboratoria wyjaśniły relację między usługą Azure a usługą Azure AD. Usługa Azure AD jest dostawcą tożsamości (IdP). W szczególności wykorzystuje OpenIDConnect, czyli strukturę opartą na OAuth. Sekcja „Dalsze informacje” zawiera linki do przewodnika Okta dotyczącego OAuth 2.0. Dlaczego tak wiele przedsiębiorstw korzysta z usługi Azure AD? Głównym powodem jest usługa Office 365. Wielu użytkowników usługi Office 365 pochodziło z lokalnego programu Exchange, a aby ułatwić synchronizację użytkowników, do synchronizacji skrzynek pocztowych i synchronizacji użytkowników użyto usługi Azure AD. Widzimy również, że wiele organizacji miało usługę Okta lub innego dostawcę tożsamości, w którym usługa Azure AD łączy się z tymi dostawcami tożsamości. Nie zdziw się, jeśli od czasu do czasu zobaczysz federację. Sama usługa Azure używa serii zakresów, aby kontrolować dostęp do zasobów. Kontrole są ustawiane według zakresu, a zakresy te definiują uprawnienia użytkowników w Azure. Microsoft Azure AD to inny typ magazynu tożsamości niż klasyczne usługi domenowe Active Directory. Znajdziesz wiele różnic między różnymi typami usług tożsamości Microsoft, jak wyjaśniono w Tabeli .

https://chacker.pl/

Teraz powinniśmy sprawdzić, czy wszystkie nasze maszyny są dostępne. Aby to zrobić, musimy zalogować się do kontrolera domeny za pomocą konta administratora. To laboratorium przeprowadzi Cię przez ten proces, zaczynając od uzyskania adresu IP kontrolera domeny.

Zaczynamy od użycia narzędzia az vm, aby wypisać wszystkie obiekty w formacie tabeli (1). W naszym środowisku widzimy trzy maszyny wirtualne: kontroler domeny (2), stację roboczą użytkownika (3) i serwer SOC/serwer ELK (4). Do stacji roboczej i kontrolera domeny można się zalogować za pomocą protokołu RDP, a serwer SOC będzie dostępny przez protokół SSH. Na potrzeby naszych laboratoriów skupimy się tylko na rtc-dc1. W tym przykładzie pokazany adres IP to 40.78.2.188 (5), ale Twój będzie inny. Użyj protokołu RDP, aby uzyskać dostęp do rtc-dc1 za pomocą nazwy użytkownika rtc.local\rtcadmin i hasła Password123. Jeśli możesz zalogować się do serwera, możesz pozostawić sesję RDP otwartą lub ją zamknąć.

https://chacker.pl/

Abyśmy mogli spróbować wykonać niektóre z naszych laboratoriów, musimy zmodyfikować niektóre elementy w Portalu. Najpierw musimy dodać użytkownika, którego możemy użyć do uzyskania dostępu do laboratorium:

W momencie pisania tego tekstu Debian „bullseye” jest w wersji wydanej, a Debian „bookworm” jest kolejną wersją Debiana. Podkreślamy to, ponieważ Kali jest dystrybucją ciągłą i musimy jak najbardziej zbliżyć się do pociągu wydań Debiana, aby zainstalować narzędzie za pomocą pliku .deb. Aby wykonać niektóre kroki w tym laboratorium, potrzebujemy narzędzia Azure CLI (1), które umożliwia nam uruchamianie poleceń Azure tak, jakbyśmy używali AWS CLI. Jednak w przeciwieństwie do AWS CLI, Azure używa OpenIDConnect, więc mamy więcej sposobów logowania się do Azure, w tym następujące:

• Przepływ kodu autoryzacji OpenIDConnect:az login
• Przepływ kodu autoryzacji OpenIDConnect określający nazwę użytkownika i hasło w monicie logowania:az login -u user -p password
• Przepływ urządzenia OpenIDConnect:az login –use-device-code
• Przepływ poświadczeń klienta OpenIDConnect:az login –service-principal

-u 123-123-123 -p password –tenant 123-123-123

Jak widać, istnieje wiele sposobów programowego wejścia do systemu. Na razie użyjemy standardowego przepływu kodu autoryzacji (2) dla systemów z pulpitem. Jeśli nie używasz środowiska pulpitu, rozważ zalogowanie się za pomocą przełączników -u/-p. Po zalogowaniu utworzymy konto użytkownika, którego możemy użyć do uwierzytelnienia się w samej platformie Azure:

Należy pamiętać, że tworzymy prawdziwe konto użytkownika z długim i silnym hasłem. Nie należy używać hasła z książki; zamiast tego należy wybrać własne długie i silne hasło, ponieważ użytkownik będzie przyznawał uprawnienia w środowisku chmury. Utworzony przez nas użytkownik nie ma uprawnień w usłudze Azure AD, więc następnym krokiem jest nadanie mu uprawnień. Istnieje kilka sposobów, aby to zrobić; najłatwiej jest wykonać następujące kroki w Azure Portal:

1. Wybierz Azure | Subskrypcje, a następnie znajdź subskrypcję, w której znajdują się zasoby. Kliknij opcję Kontrola dostępu (IAM) po lewej stronie.
2. Kliknij Przypisania ról, a następnie kliknij Dodaj przypisanie roli. Wykonanie tego obejmuje trzy kroki:
3. Znajdź rolę.
4. Znajdź członków.
5. Dokonaj przypisania. Na pierwszym ekranie należy wybrać Czytelnika.
6. Kliknij Dalej. W przypadku członków wybierz naszego użytkownika ghh-test-user. Kliknij Wybierz członków, aby wybrać tego użytkownika.
7. Na koniec kliknij Wyświetl i przypisz.

Teraz, gdy skonfigurowaliśmy naszego użytkownika, musimy nadać jednej z naszych maszyn wirtualnych zarządzaną tożsamość przypisaną przez system. Oto kroki, które należy wykonać:

1. W Azure Portal kliknij grupę zasobów utworzoną przez PurpleCloud. Będzie się nazywać purplecloud-devops1.
2. Po wyświetleniu zasobów kliknij rtc-dc1. W tym obszarze kliknij element tożsamości w obszarze ustawień po lewej stronie.
3. Kliknij Status na Włączone. Może być konieczne kliknięcie Zapisz, aby kontynuować.
4. Teraz zobaczysz przycisk Przypisania ról platformy Azure. Kliknij przycisk, aby dodać przypisanie roli.
5. Możesz lub nie musisz wybrać subskrypcji; jeśli masz więcej niż jedną, będziesz musiał wybrać subskrypcję z listy w obszarze zakresów ekranu. Wybierz swoją subskrypcję, a następnie wybierz rolę Współpracownik.

Należy pamiętać, że jest to dość wysoki poziom dostępu; w tym momencie powinieneś zablokować listę kontroli dostępu tylko do swojego adresu IP. Jeśli tego nie zrobiłeś, zmodyfikuj plik terraform.tfvas i uruchom Terraform ponownie, aby zaktualizować konfigurację.

https://chacker.pl/

Będziemy korzystać z projektu znanego jako PurpleCloud autorstwa Jasona Ostroma. PurpleCloud wykorzystuje Terraform i Ansible, aby uruchomić Twoje środowisko. Samo PurpleCloud wymaga kilku uprawnień:

• Wymaga skonfigurowania subskrypcji Microsoft Azure.
• Musisz upewnić się, że Terraform i Ansible są nadal na Twoim

komputerze.

• Musisz skonfigurować konto usługi Azure.
• Musisz zainstalować Azure CLI od Microsoft.

Na dole repozytorium GitHub, do którego odwołuje się laboratorium, zobaczysz łącze do witryny dokumentacji. Witryna zawiera sekcję dotyczącą tworzenia kont usług.

Laboratoria w tym rozdziale mogą kosztować sporo pieniędzy na zasób. Jedną z dostępnych opcji jest „zatrzymanie” maszyn — nie zakończenie, tylko „zatrzymanie” — po godzinie działania laboratoriów. Dałoby Ci to możliwość budowania laboratoriów, ale nie musiałbyś ich niszczyć za każdym razem. Koszt tego laboratorium działającego przez miesiąc może wynieść kilkaset dolarów ze względu na maszyny wirtualne Windows z licencją Microsoft działające w Azure. Zacznijmy od wdrożenia PurpleCloud, zrobimy to poprzez rozwidlenie kodu.

Pierwszym krokiem jest sklonowanie repozytorium PurpleCloud (1). Samo repozytorium zawiera wiele skryptów Terraform w katalogu wdrażania (2). Po przejściu do katalogu należy przenieść plik terraform.tfexample do terraform.tfvars (3). Następnie należy edytować plik i zmienić kilka ustawień (4). Oto odpowiednie obszary, które należy zmienić w pliku tfexample:

Dostarczony obraz pokazuje, jak uzyskać dostęp do tych wartości (5) za pomocą Azure Portal. Jeśli używasz Azure Portal, możesz znaleźć te wartości, wybierając Azure Active Directory | Rejestracje aplikacji, a następnie klikając swoją aplikację. Po wypełnieniu wartości w pliku konfiguracyjnym możesz znaleźć wartości, aby wypełnić te elementy w pliku. Będziesz musiał wygenerować klucz tajny klienta, który można znaleźć w obszarze Certyfikaty i sekrety aplikacji. W tym pliku masz również opcję edycji src_ip, aby zablokować dostęp do odsłoniętych systemów. Uruchom polecenia terraform, aby zbudować system.

Określając plik var (6) w Terraform, możesz teraz wdrożyć go do swojego dzierżawcy. Ten proces zajmie kilka minut. Należy pamiętać, że zostaną wyświetlone dane wyjściowe dotyczące zewnętrznych adresów IP, które nie będą wyświetlane bezpośrednio, ale znajdziemy te adresy, przechodząc przez nasze laboratoria. Można również zmodyfikować pliki tak, aby dostęp zewnętrzny nie był dozwolony i aby były używane tylko wewnętrzne adresy IP. Jest to udokumentowane w samym PurpleCloud, a nie tutaj.

https://chacker.pl/

Ponieważ omówiliśmy AWS, dobrze byłoby omówić główne różnice, które możesz znaleźć między tymi dwoma środowiskami chmurowymi — konkretnie, jako atakujący, co może cię zaskoczyć. Pierwsza z nich to fakt, że wiele organizacji korzysta z Azure AD w pewnym zakresie. AWS nie udostępnia użytkownikom dostawcy tożsamości (IdP); zamiast tego używają kluczy API do dostępu programowego. AWS używa swojego IAM, aby dokładnie opisać, z których usług i zasobów możesz korzystać w systemie AWS. Jeśli korzystasz z Azure lub AWS i próbujesz przenosić zasoby między tymi dwoma systemami, uprawnienia i struktury będą się bardzo różnić w ich zastosowaniu. Może to cię zdezorientować lub po prostu może ci się nie podobać sposób, w jaki działają w porównaniu. Poza uprawnieniami, inną główną różnicą między AWS i Azure, którą znajdziesz, są niektóre gotowe funkcje w tych usługach. Azure ma wiele gotowych sposobów automatyzacji zarządzania systemami. Maszyny wirtualne platformy Azure mają funkcję o nazwie „run-command”, która umożliwia wykonywanie kodu. Istnieje również szereg opcji w narzędziach, takich jak Custom Script. Rozszerzenia do wykonywania operacji systemowych. Te zestawy narzędzi są wbudowane i udostępniane domyślnie; w przeciwieństwie do tego AWS wymaga skonfigurowania narzędzi do tego celu. Wreszcie istnieją różnice w sposobie tworzenia niektórych usług, z bardzo małym oddzieleniem na tym samym hoście. Jednym z przykładów jest Azure Functions dla systemu Windows. Azure Functions są jak Lambda w AWS, z subtelnymi różnicami. Funkcje platformy Azure w systemie Windows, które są tworzone w tej samej „aplikacji”, współdzielą ten sam dysk i nie mają oddzielenia dysków. Dzieje się tak, ponieważ system Windows historycznie nie tworzył kontenerów, dlatego Azure Functions dla systemu Windows ma ten problem. Azure wykorzystuje koncepcję konta użytkownika lub podmiotu usługi, który jest podobny do konta usługi. Azure AD, ponieważ jest dostawcą tożsamości, może używać różnych przepływów OAuth. Różni się to od AWS, który używa statycznych lub ulotnych kluczy API. Oznacza to również, że będziemy przeprowadzać ataki uwierzytelniające oparte na nazwie użytkownika i haśle na interfejsy API w usłudze Azure, ponieważ uzyskanie dostępu do tych użytkowników wymaga zarówno dostępu przez sieć Web, jak i przez interfejs wiersza poleceń (CLI), co jest potężnym rozwiązaniem.

https://chacker.pl/

Microsoft Azure ma kilka komponentów skierowanych do deweloperów i rozszerzył się o coraz więcej ogólnych środowisk obliczeniowych IT. Kluczowym elementem organizacji Azure jest zrozumienie struktury, w której mogą znajdować się zasoby. Ta koncepcja jest podobna do sposobu działania Amazon Organizations, z dużymi różnicami w sposobie stosowania reguł IAM. Zobaczymy wpływ na tę organizację w zakresie tego, jak możemy atakować same zasoby Azure. Azure wykorzystuje koncepcję znaną jako subskrypcje2 do organizowania wielu swoich zasobów. Subskrypcje Azure są organizowane przez grupy zarządzania. Pojedyncza grupa zarządzania może zarządzać wieloma subskrypcjami, które mogą zarządzać wieloma grupami zasobów. Grupy zasobów zawierają zasoby. Model jest hierarchiczny, a dziedziczenie jest funkcją. „Właściciel” lub „Współpracownik” na poziomie grupy zarządzania odziedziczy uprawnienia w dół. Jest to krytyczne, aby to zrozumieć, ponieważ stosowanie uprawnień na szczycie drzewa będzie miało wpływ w dół.

http://chacker.pl

Platforma chmurowa Microsoftu jest znana jako Microsoft Azure. Jest uważana za platformę infrastruktury jako usługi (IaaS), ale Microsoft Azure nie zaczynał w ten sposób; zaczął jako technologia platformy jako usługi (PaaS). W związku z tym znaczna część oryginalnego systemu była ukierunkowana na doświadczenie wielodostępne z jego bazą użytkowników. Platforma chmurowa Microsoftu działa inaczej niż platforma Amazon w subtelny sposób, który my, jako atakujący, możemy nadużyć. Oto kilka przykładów różnic w Azure:

• Mechanizm, w którym musisz zorganizować zasoby, wpłynie na sposób działania kontroli dostępu.
• Standardowe maszyny wirtualne Azure mają o wiele więcej możliwości wykorzystania, z bardziej złożonym sposobem ograniczania dostępu.
• Tożsamości używają OpenID Connect, ponieważ Microsoft ściśle zintegrował Azure AD z Azure, co jest dużą różnicą w porównaniu ze statycznymi kluczami API AWS.

Trudno jest również omawiać Microsoft Azure bez omawiania Azure Active Directory firmy Microsoft. Przeczytasz fragmenty odnoszące się do platformy Azure, a zamiast tego skupiające się na usłudze Azure AD ze względu na ścisłą integrację obu systemów.

https://chacker.pl/

Jednym z bardzo tradycyjnych mechanizmów trwałości w standardowym systemie operacyjnym jest zaplanowane zadanie. W systemie Windows masz harmonogram zadań, a w systemie Linux masz demona cron. Każdy z tych systemów ma zdarzenie wyzwalające; zazwyczaj jest ono oparte na czasie i działaniu. Co by było, gdybyśmy mogli dowiedzieć się, jak wyzwolić zadanie w ekosystemie AWS, które zapewniłoby nam trwałość? Ryan Gerstenkorn z Rhino Security Labs napisał narzędzie oparte na Go, które może pomóc symulować dokładnie taką sytuację. Narzędzie nazywa się UserDataSwap. Może być bardzo przydatne, jeśli masz odpowiednie uprawnienia i wiesz, jak modyfikować źródło. Narzędzie napisane w Go ma statyczne polecenie rozruchu, które doda statycznie skompilowaną wersję Netcata i otworzy nasłuchiwacza tylnych drzwi. Port nasłuchiwacza pozostaje otwarty w systemie hosta. Pomyśl o tym jako o połączeniu bootloadera tylnych drzwi i modułu trwałości w systemie operacyjnym.

Jak zauważysz, najpierw uruchamiamy polecenie wyjściowe terraform (1), aby znaleźć lokalizację kontenera S3 dla naszego narzędzia. Robimy to w samym katalogu terraform. Następnie musimy zmodyfikować plik samconfig.toml (2) w katalogu UserDataSwap znajdującym się w instancji Kali w AWS. Plik wymaga modyfikacji jednego wpisu, którym jest wpis s3_sam_bucket (3):

Gdy plik samconfig.toml zostanie ukończony, możemy wykonać polecenia kompilacji i wdrożenia:

Pierwsze polecenie, make build (4), skompiluje aplikację lokalnie. Następnie uruchomienie polecenia make deploy (5) spowoduje utworzenie funkcji Lambda, która przyjmie most zdarzeń jako wyzwalacz. Będzie ona szukać instancji EC2, które się uruchamiają, a te instancje EC2, które się uruchamiają, wyzwolą most zdarzeń, aby wyzwolić funkcję Lambda. Po wyzwoleniu funkcji Lambda przyjmie ona identyfikator instancji jako cel i zapisze dane użytkownika. Funkcja Lambda poinstruuje serwer EC2, aby się wyłączył, zamienił dane użytkownika i uruchomił instancję. Po zakończeniu tego procesu wykona tę samą operację, aby zamienić z powrotem oryginalne dane użytkownika. Administratorowi będzie się wydawać, że EC2 po prostu działa znacznie wolniej niż zwykle. Ważne jest również, aby zauważyć, że skalowanie automatyczne nie zostało przetestowane i może spowodować, że sytuacja wymknie się spod kontroli. Nie włączaj skalowania automatycznego w tej konfiguracji. Implant, którego używamy, to port nasłuchujący Netcat na każdej instancji EC2 na porcie 1234. Teraz musimy zbudować serwer EC2 do testów! Na szczęście możemy przejść do innego katalogu Terraform, aby zbudować urządzenie ofiary (4):

W tym momencie musimy odczekać około 5 lub 6 minut, aby UserDataSwap wykonał wszystkie operacje, których potrzebuje. Możesz sprawdzić w grupie logów CloudWatch (https://console.aws.amazon.com/cloudwatch/home?region=us-east-1#logsV2:log-groups), która byłaby najnowszą grupą ze słowami „UserDataSwap-UserDataSwapFunction”, aby zobaczyć status wykonania funkcji. Teraz spróbujemy połączyć się z systemem, który otworzyliśmy. Powłoka będąca surową powłoką gniazda może być połączona za pomocą netcat.

Teraz możemy połączyć się z naszą maszyną z tej samej sieci VPC, aby zobaczyć, że port jest rzeczywiście otwarty. Tutaj uruchamiamy polecenie nc (7) na maszynie docelowej; pamiętaj, że nie będzie żadnego monitu z netcat. Możemy uruchomić ls (8) i whoami (9), aby przetestować działanie.

Podsumowanie

Amazon Web Services to bardzo potężny i użyteczny zestaw narzędzi, który daje nam możliwość dostarczania usług, oprogramowania, aplikacji i innych rzeczy na taką samą skalę jak sam Amazon. Powinniśmy jednak patrzeć na Amazon Web Services nie jako na środowisko usług w chmurze, ale jako na system operacyjny. Dzieli wiele właściwości tradycyjnego systemu operacyjnego, eksponowanych w unikalny sposób. Ma model uprawnień podobny do naszych systemów operacyjnych, ma zestaw systemów plików i może uruchamiać, planować i pracować z aplikacjami i procesami. Mając to na uwadze, możemy również atakować i nadużywać Amazon Web Services w bardzo znajomy sposób. Mamy nadzieję, że ten rozdział rozpocznie Cię ścieżką bliższego przyjrzenia się Amazon Web Services.

https://chacker.pl/

Jak wspomniano wcześniej, RedBoto składa się z serii skryptów, a jeden ze skryptów służy do eksploatowania usług AWS. Niektóre skrypty RedBoto są zaprojektowane jako jednorazowe, z niewielką lub żadną jednolitością lub obsługą błędów. Mimo to dla wielu osób korzystających z nich praktyczność jest kluczowa. Uruchommy nasz pierwszy skrypt:

Skrypt describeInstances.py (1) to prosty skrypt wyliczeniowy EC2, który działa na liście regionów (2). Chociaż nie jest to pełna lista regionów, skrypt został zaprojektowany z myślą o prostocie, a nie złożoności. Możemy zobaczyć identyfikatory instancji (3), nazwę komputera i jego stan. Uruchommy następny skrypt:

UWAGA UserData to specjalne pole, które można osadzić w każdej instancji EC2, aby umożliwić dostosowywanie maszyny w czasie rozruchu. Typowy mechanizm używany do odczytu i wykonywania danych użytkownika to framework o nazwie cloudinit. Mechanizm ten jest zaprojektowany do uruchamiania opcjonalnych danych użytkownika podczas rozruchu w celu wykonywania operacji bootstrapowych w systemach operacyjnych. Możemy nadużywać tej funkcji, wstawiając lub odczytując dane użytkownika.

Następny skrypt describeUserData.py (4) przejdzie w ciemno przez każdą instancję i wyliczy wszystkie dane użytkownika (5) przechowywane w konfiguracji instancji. Jak widać, można tu przechowywać dowolną liczbę elementów, w tym nazwy użytkowników i hasła (6). To nie jest dobry wzorzec przechowywania informacji, ale nadal widzimy go w użyciu. Ważne jest, aby szukać haseł w danych użytkownika i innych kluczowych elementach danych.

Systemy operacyjne Windows w EC2 sprawiają, że dane użytkownika są o wiele bardziej interesujące. Częścią procesu tworzenia niektórych systemów operacyjnych Windows jest posiadanie nazwy użytkownika Administrator. Czasami pseudolosowo utworzone hasło jest szyfrowane przy użyciu klucza SSH używanego na koncie. Gdybyśmy mieli dostęp do tego klucza SSH, czy moglibyśmy odszyfrować tę wartość? RedBoto ma skrypt, który robi właśnie to:

WSKAZÓWKA: Upewnij się, że skopiowałeś swój ~/.ssh/id_rsa z dowolnego urządzenia, którego użyłeś do zbudowania swoich początkowych maszyn, na maszynę, którą atakujesz. Ważne jest również, aby zauważyć, że ta wersja getEC2WinCreds.py została zmodyfikowana, aby działała z naszymi laboratoriami. Oryginalny skrypt opiera się na fakcie, że mamy plik PEM dla naszego klucza SSH, ale używamy kluczy w formacie OpenSSH. Ta wersja nie próbuje deserializować plików PEM.

Używając pliku getEC2WinCreds.py (7), system automatycznie sprawdzi określony region i wyliczy wszystkie wystąpienia EC2 (8), szukając konkretnie platformy Windows jako klucza. Następnie skrypt przejdzie do każdego z zlokalizowanych identyfikatorów wystąpień i, używając klucza SSH jako klucza deszyfrującego, spróbuje odszyfrować każde z pól hasła (9). Zapewnia również wgląd w publiczny adres IP. Jeśli zostanie znaleziony, nastąpi zmiana, która ujawni port RDP w Internecie i umożliwi zdalny dostęp do urządzenia.

https://chacker.pl/

Jednym z największych wyzwań, z jakimi przyjdzie Ci się zmierzyć w przypadku wielu narzędzi AWS, jest kompletność pokrycia. Większość narzędzi ma ograniczenia dotyczące tego, co mogą zrobić bez wprowadzania przez nas zmian, a nadążanie za wysokim tempem zmian może być problemem. Zobaczmy, gdzie nasze narzędzia mają pewne ograniczenia i zalety:

Czy chciałbyś wykonać kilkaset wywołań API, aby spróbować zweryfikować, które uprawnienia do opisu (lub odczytu) masz w EC2 i Lambda? Prawdopodobnie nie. Jak możemy to zrobić w bardziej zautomatyzowany sposób? Po prostu używamy PACU i znajdujemy wszystkie uprawnienia — czy możemy?

Aby uruchomić narzędzie PACU z katalogu /opt/pacu (1) na komputerze Kali Linux, należy uruchomić plik Pythona cli.py (2). PACU organizuje kampanie według nazwy sesji; my nazwaliśmy naszą bieżącą sesję „ghh” (3). PACU może używać kluczy, które znajdują się już w ogólnym systemie operacyjnym. Aby to zrobić, użyjemy polecenia import_keys –all (4), aby zaimportować wszystkie profile i klucze zapisane w pliku poświadczeń. Po załadowaniu tych elementów możemy zacząć używać modułów. Jednym z modułów, których możemy użyć, jest moduł do wywoływania usługi IAM i brutalnego wymuszania uprawnień. Robimy to za pomocą polecenia run iam__bruteforce_permissions (5). Można by założyć, że jest to w 100% kompletny sposób na znalezienie wszystkich uprawnień w systemie, tak jak jest opisany. Tak nie jest. Jak zobaczysz później, to polecenie spróbuje wywołać API AWS, ale tylko dla określonych usług, takich jak EC2 i Lambda, i tylko dla bardzo wąskich wywołań API — głównie tych, które są przydatne w opisywaniu usług (polecenia oparte na odczycie). Możemy zobaczyć, co znaleźliśmy dla naszego klucza API, wywołując whoami (4). Polecenie wyświetli niektóre dozwolone i zabronione uprawnienia, ale nie jest ono w 100 procentach kompletne. Innym sposobem na osiągnięcie tego samego typu wyniku jest próba użycia każdego wywołania API. Następnie wyliczymy ec2_hosts (7) jako przykład walidacji naszych znanych uprawnień. Zobaczysz, że możemy wyliczyć większość danych EC2. PACU próbuje zbudować w pełni funkcjonalny moduł z dołączonymi bateriami do eksploatacji AWS, ale ma swoje wady. Nie zawsze zawiera każdy moduł, którego możesz potrzebować. Nie obsługuje również każdej usługi w AWS. Często musisz polegać na innych narzędziach, skryptach lub po prostu zwykłym interfejsie wiersza poleceń AWS, aby wykonać wiele ataków, które chcesz wykonać. Pokazujemy kilka przykładów w następnej sekcji. Chcemy jednak, abyś nadal korzystał z PACU, ponieważ ma on kilka przydatnych funkcji, takich jak:

• Zezwalanie użytkownikowi na backdoorowanie usługi EC2 za pomocą skryptu rozruchowego
• Umieszczanie adresu IP na białej liście w GuardDuty, czyli usłudze wykrywania zagrożeń z AWS
• Wykorzystywanie narzędzia Amazon SSM do wykonywania poleceń
• Backdoorowanie kont użytkowników poprzez dodanie zestawu kluczy API lub, w niektórych przypadkach, dodanie drugiego zestawu kluczy API
• Pobieranie różnych typów zestawów danych, takich jak migawki bazy danych RDS i pliki S3

UWAGA: Wiele działań w tej sekcji zostanie zalogowanych w komponentach CloudTrail konsoli AWS; jest to robione domyślnie. Chociaż rejestrowanie jest dobre, samo w sobie nie wystarczy, aby zrozumieć, co się dzieje. Potrzebujesz dodatkowych narzędzi, aby pobrać dzienniki i lepiej je zrozumieć, tak jak w standardowym systemie operacyjnym. Sekcja jest bardzo głośna i może pozostawić duży ślad.