diff --git a/src/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/README.md b/src/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/README.md index 31b575af9..0fc209b5a 100644 --- a/src/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/README.md +++ b/src/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/README.md @@ -6,17 +6,17 @@ ### Tenant Enumeration -Istnieją pewne **public Azure APIs**, dzięki którym atakujący, znając tylko **domenę tenant'a**, może wykonać zapytania, aby zebrać więcej informacji o nim.\ -Możesz zapytać bezpośrednio API lub użyć biblioteki PowerShell [**AADInternals**](https://github.com/Gerenios/AADInternals) (`Install-Module AADInternals`): +Istnieją pewne **publiczne Azure APIs**, które, znając jedynie **domenę tenant**, atakujący może odpytać, aby zebrać o nim więcej informacji.\ +Możesz odpytać bezpośrednio API albo użyć biblioteki PowerShell [**AADInternals**](https://github.com/Gerenios/AADInternals) (`Install-Module AADInternals`): -- **Informacje o logowaniu, w tym tenant ID** +- **Informacje logowania, w tym tenant ID** - `Get-AADIntTenantID -Domain ` (main API `login.microsoftonline.com//.well-known/openid-configuration`) -- **Wszystkie poprawne domeny w tenant** +- **Wszystkie poprawne doimains w tenant** - `Get-AADIntTenantDomains -Domain ` (main API `autodiscover-s.outlook.com/autodiscover/autodiscover.svc`) -- **Informacje o logowaniu użytkownika**. Jeśli `NameSpaceType` jest `Managed`, oznacza to, że używane jest EntraID +- **Informacje logowania użytkownika**. Jeśli `NameSpaceType` to `Managed`, oznacza to, że używany jest EntraID - `Get-AADIntLoginInformation -UserName ` (main API `login.microsoftonline.com/GetUserRealm.srf?login=`) -Możesz uzyskać wszystkie informacje o Azure tenant za pomocą **jednego polecenia z** [**AADInternals**](https://github.com/Gerenios/AADInternals): +Możesz zebrać wszystkie informacje o Azure tenant za pomocą **jednej komendy z** [**AADInternals**](https://github.com/Gerenios/AADInternals): ```bash # Doesn't work in macos because 'Resolve-DnsName' doesn't exist Invoke-AADIntReconAsOutsider -DomainName corp.onmicrosoft.com | Format-Table @@ -35,33 +35,46 @@ company.mail.onmicrosoft.com True True True Managed company.onmicrosoft.com True True True Managed int.company.com False False False Managed ``` -Można zobaczyć szczegóły dotyczące nazwy tenanta, ID oraz nazwy "brand". Dodatkowo wyświetlany jest status Desktop Single Sign-On (SSO), znanego również jako [**Seamless SSO**](https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sso). Po włączeniu funkcja ta ułatwia ustalenie obecności (enumerację) konkretnego użytkownika w docelowej organizacji. +Możliwe jest zaobserwowanie szczegółów dotyczących nazwy tenant, ID oraz nazwy „brand”. Dodatkowo wyświetlany jest status Desktop Single Sign-On (SSO), znanego również jako [**Seamless SSO**](https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sso). Gdy jest włączone, ta funkcja ułatwia określenie obecności (enumeration) konkretnego usera w docelowej organizacji. -Dodatkowo wynik przedstawia nazwy wszystkich zweryfikowanych domen powiązanych z docelowym tenantem wraz z ich typami tożsamości. W przypadku domen federowanych ujawniany jest również Fully Qualified Domain Name (FQDN) dostawcy tożsamości w użyciu, zazwyczaj serwera ADFS. Kolumna "MX" określa, czy wiadomości e-mail są kierowane do Exchange Online, natomiast kolumna "SPF" wskazuje, czy Exchange Online jest wymienione jako nadawca e-maili. Ważne: aktualna funkcja rozpoznawcza nie parsuje instrukcji "include" w rekordach SPF, co może skutkować fałszywie negatywnymi wynikami. +Ponadto output prezentuje nazwy wszystkich zweryfikowanych domains powiązanych z docelowym tenant, wraz z ich odpowiednimi typami tożsamości. W przypadku federated domains ujawniana jest również Fully Qualified Domain Name (FQDN) identity provider używanego w danym momencie, zazwyczaj serwera ADFS. Kolumna "MX" określa, czy maile są kierowane do Exchange Online, natomiast kolumna "SPF" oznacza wskazanie Exchange Online jako sender maila. Należy zauważyć, że obecna funkcja reconnaissance nie parsuje instrukcji "include" w rekordach SPF, co może prowadzić do false negatives. -### Enumeracja użytkowników +### User Enumeration > [!TIP] -> Należy pamiętać, że nawet jeśli tenant używa kilku adresów e-mail dla tego samego użytkownika, **username is unique**. Oznacza to, że będzie to działać tylko z domeną powiązaną z użytkownikiem, a nie z innymi domenami. +> Zwróć uwagę, że nawet jeśli tenant używa kilku emails dla tego samego usera, **username jest unikalny**. Oznacza to, że będzie to działać tylko z domain, którą user ma powiązaną, a nie z innymi domains. -Można **sprawdzić, czy username istnieje** w obrębie tenanta. Dotyczy to również **guest users**, których username ma format: +Możliwe jest **sprawdzenie, czy username istnieje** w obrębie tenant. Obejmuje to również **guest users**, których username ma format: ``` #EXT#@.onmicrosoft.com ``` -Adres e-mail to adres użytkownika, w którym znak „@” został zastąpiony znakiem podkreślenia „\_”. +Adres email to adres email użytkownika, gdzie „@” jest zastąpione podkreśleniem „\_“. Za pomocą [**AADInternals**](https://github.com/Gerenios/AADInternals) możesz łatwo sprawdzić, czy użytkownik istnieje, czy nie: ```bash # Check does the user exist Invoke-AADIntUserEnumerationAsOutsider -UserName "user@company.com" ``` -Nie otrzymałem treści pliku README.md. Proszę wklej zawartość (z zachowaniem oryginalnego markdown/html), a przetłumaczę ją na polski zgodnie z wytycznymi. +W tym rozdziale omówimy, jak enumerate Azure tenant, bazując na publicznie dostępnym, anonimowym acceso, oraz jak znaleźć punkty wejścia. + +Azure oferuje kilka publicznie dostępnych endpointów, które można wykorzystać do anonimowego enumeration. Niektóre z nich ujawniają informacje o tenant, domenach, użytkownikach, aplikacjach i konfiguracji. + +Typowe techniki obejmują: +- pobieranie metadata z publicznych endpointów, +- wykorzystanie OpenID Connect discovery, +- sprawdzanie odpowiedzi na niepoprawne login attempts, +- analizę komunikatów błędów, +- wykorzystywanie publicznych zasobów, takich jak `autodiscover`, `portal`, `login` i inne usługi związane z Azure. + +Zebrane informacje mogą pomóc w initial entry, identyfikacji interesujących użytkowników i zrozumieniu powierzchni ataku. + +W kolejnych sekcjach pokażemy konkretne techniki i przykłady. ``` UserName Exists -------- ------ user@company.com True ``` -Możesz też użyć pliku tekstowego z jednym adresem e-mail na wiersz: +Możesz też użyć pliku tekstowego zawierającego jeden adres email na wiersz: ``` user@company.com user2@company.com @@ -75,22 +88,22 @@ external.user_outlook.com#EXT#@company.onmicrosoft.com # Invoke user enumeration Get-Content .\users.txt | Invoke-AADIntUserEnumerationAsOutsider -Method Normal ``` -Obecnie dostępne są **4 różne metody enumeracji** do wyboru. Informacje można znaleźć w `Get-Help Invoke-AADIntUserEnumerationAsOutsider`: +Currenlty dostępne są **4 różne metody enumeracji** do wyboru. Informacje można znaleźć w `Get-Help Invoke-AADIntUserEnumerationAsOutsider`: Obsługuje następujące metody enumeracji: Normal, Login, Autologon i RST2. -- Metoda **Normal** wydaje się obecnie działać we wszystkich tenants. Wcześniej wymagała włączenia Desktop SSO (aka Seamless SSO) dla przynajmniej jednej domeny. +- Metoda **Normal** wydaje się obecnie działać ze wszystkimi tenantami. Wcześniej wymagała włączenia Desktop SSO (czyli Seamless SSO) dla co najmniej jednej domeny. -- Metoda **Login** działa w każdym tenants, ale zapytania enumeracyjne będą rejestrowane w Azure AD sign-in log jako nieudane zdarzenia logowania! +- Metoda **Login** działa z dowolnym tenantem, ale zapytania enumeracyjne będą logowane do Azure AD sign-in log jako failed login events! -- Metoda **Autologon** wydaje się już nie działać we wszystkich tenants. Prawdopodobnie wymaga, aby DesktopSSO lub directory sync były włączone. +- Metoda **Autologon** nie wydaje się już działać ze wszystkimi tenantami. Prawdopodobnie wymaga, aby DesktopSSO lub directory sync było włączone. -Po odkryciu poprawnych nazw użytkowników możesz uzyskać **informacje o użytkowniku** za pomocą: +Po odkryciu prawidłowych nazw użytkowników możesz uzyskać **info o użytkowniku** za pomocą: ```bash Get-AADIntLoginInformation -UserName root@corp.onmicrosoft.com ``` -Skrypt [**o365spray**](https://github.com/0xZDH/o365spray) pozwala również sprawdzić **czy adres e-mail jest prawidłowy**. +Skrypt [**o365spray**](https://github.com/0xZDH/o365spray) także pozwala odkryć, **czy email jest poprawny**. ```bash git clone https://github.com/0xZDH/o365spray cd o365spray @@ -103,13 +116,13 @@ python3 ./o365spray.py --enum -d carloshacktricks.onmicrosoft.com -U /tmp/users. ``` **User Enumeration via Microsoft Teams** -Innym dobrym źródłem informacji jest Microsoft Teams. +Kolejnym dobrym źródłem informacji jest Microsoft Teams. -API Microsoft Teams umożliwia wyszukiwanie użytkowników. W szczególności endpointy "user search" **externalsearchv3** i **searchUsers** mogą być użyte do pobrania ogólnych informacji o kontach użytkowników zarejestrowanych w Teams. +API Microsoft Teams umożliwia wyszukiwanie użytkowników. W szczególności endpointy "user search" **externalsearchv3** oraz **searchUsers** mogą być użyte do pobierania ogólnych informacji o kontach użytkowników zapisanych do Teams. -W zależności od odpowiedzi API można rozróżnić między użytkownikami nieistniejącymi a istniejącymi użytkownikami posiadającymi ważną subskrypcję Teams. +W zależności od odpowiedzi API możliwe jest rozróżnienie między nieistniejącymi użytkownikami a istniejącymi użytkownikami, którzy mają aktywną subskrypcję Teams. -Skrypt [**TeamsEnum**](https://github.com/lucidra-security/TeamsEnum) może służyć do weryfikacji podanego zestawu nazw użytkowników za pomocą Teams API, ale wymaga dostępu do konta użytkownika z dostępem do Teams. +Skrypt [**TeamsEnum**](https://github.com/lucidra-security/TeamsEnum) może być użyty do sprawdzenia danego zestawu nazw użytkowników względem API Teams, ale do jego użycia potrzebujesz dostępu do użytkownika z dostępem do Teams. ```bash # Install git clone https://github.com/lucidra-security/TeamsEnum @@ -119,25 +132,75 @@ python3 -m pip install -r requirements.txt # Login and ask for password python3 ./TeamsEnum.py -a password -u -f inputlist.txt -o teamsenum-output.json ``` -I don't have the README.md content. Proszę wklej zawartość pliku README.md, którą chcesz przetłumaczyć na polski. +## Azure Unauthenticated Enum and Initial Entry + +In Azure, możliwe jest przeprowadzenie **unauthenticated enum** w celu zebrania informacji o tenantach, subskrypcjach, użytkownikach i usługach, a następnie użycie tych danych do **initial entry**. + +Typowe źródła informacji obejmują: + +- publicznie dostępne endpointy +- błędnie skonfigurowane usługi +- wycieki z aplikacji webowych +- metadata exposed by Azure services +- nieprawidłowo ujawnione artefakty w storage + +W praktyce często zaczyna się od: + +1. identyfikacji tenant name +2. enumeracji domen i userów +3. sprawdzenia endpointów logowania +4. analizy dostępnych usług i ról +5. szukania weak points, które umożliwią initial access + +Kluczowe techniki obejmują: + +- **unauthenticated requests** do publicznych API +- **subdomain enumeration** +- **OSINT** +- analiza błędów i odpowiedzi serwerów +- sprawdzanie, czy aplikacja ujawnia tenant-specific data + +Po uzyskaniu wystarczających informacji można próbować wejścia przez: + +- phishing +- credential stuffing +- token abuse +- misconfigurations +- exposed secrets +- weak authentication flows + +W Azure bardzo ważne jest rozróżnienie między tym, co jest publicznie widoczne, a tym, co wymaga authentication. Często nawet niewielkie wycieki metadanych znacząco ułatwiają dalszą enumerację i initial access. ``` [-] user1@domain - Target user not found. Either the user does not exist, is not Teams-enrolled or is configured to not appear in search results (personal accounts only) [+] user2@domain - User2 | Company (Away, Mobile) [+] user3@domain - User3 | Company (Available, Desktop) ``` -Ponadto możliwe jest wyenumerowanie informacji o dostępności istniejących użytkowników, takich jak: +Ponadto możliwe jest wyliczenie informacji o dostępności dotyczących istniejących użytkowników, takich jak: -- Dostępny -- Nieobecny -- Nie przeszkadzać -- Zajęty -- Niedostępny +- Available +- Away +- DoNotDisturb +- Busy +- Offline -Jeśli skonfigurowano **wiadomość poza biurem**, możliwe jest również pobranie tej wiadomości przy użyciu TeamsEnum. Jeśli określono plik wyjściowy, wiadomości poza biurem są automatycznie zapisywane w pliku JSON: +Jeśli skonfigurowano **out-of-office message**, możliwe jest również pobranie wiadomości za pomocą TeamsEnum. Jeśli określono plik wyjściowy, wiadomości out-of-office są automatycznie zapisywane w pliku JSON: ``` jq . teamsenum-output.json ``` -Proszę wklej zawartość pliku src/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/README.md, który chcesz przetłumaczyć na polski. +Azure Security +# Unauthenticated Enum and Initial Entry + +W wielu organizacjach Azure Authentication jest skonfigurowane tak, że konta z **włączonym MFA** nie mogą korzystać z **Basic Authentication**. +Jednak nadal można się uwierzytelnić w **Microsoft Graph** i uzyskać dostęp do danych, takich jak: + +- **User data** +- **Emails** +- **Files** +- **Channels** + +To oznacza, że jeśli uda się zdobyć poświadczenia użytkownika, nawet przy włączonym MFA, można z nich skorzystać, o ile dostęp do Basic Authentication jest nadal możliwy dla danego scenariusza. + +Istnieje kilka metod, aby przejść od samego użytkownika do dalszej enumeracji i initial entry. ```json { "email": "user2@domain", @@ -192,9 +255,10 @@ Proszę wklej zawartość pliku src/pentesting-cloud/azure-security/az-unauthent az-password-spraying.md {{#endref}} -## Usługi Azure używające domen +## Azure Services using domains -Można również spróbować znaleźć **usługi Azure ujawnione** w popularnych subdomenach Azure, takich jak opisane w tym [poście:](https://www.netspi.com/blog/technical-blog/cloud-penetration-testing/enumerating-azure-services/) +Możliwe jest też próbowanie znalezienia **Azure services exposed** w popularnych azure subdomains, takich jak te udokumentowane w tym [post: +](https://www.netspi.com/blog/technical-blog/cloud-penetration-testing/enumerating-azure-services/) - App Services: `azurewebsites.net` - App Services – Management: `scm.azurewebsites.net` @@ -215,32 +279,69 @@ Można również spróbować znaleźć **usługi Azure ujawnione** w popularnych - Search Appliance: `search.windows.net` - API Services: `azure-api.net` -Możesz użyć metody z [**MicroBust**](https://github.com/NetSPI/MicroBurst) w tym celu. Funkcja przeszuka nazwę domeny bazowej (oraz kilka permutacji) w kilku **domenach Azure:** +Możesz użyć metody z [**MicroBust**](https://github.com/NetSPI/MicroBurst) do takiego celu. Ta funkcja będzie wyszukiwać nazwę domeny bazowej (i kilka permutacji) w kilku **azure domains:** ```bash Import-Module .\MicroBurst\MicroBurst.psm1 -Verbose Invoke-EnumerateAzureSubDomains -Base corp -Verbose ``` ## Phishing -- [**Common Phishing**](https://book.hacktricks.wiki/en/generic-methodologies-and-resources/phishing-methodology/index.html) do pozyskania credentials lub przez [OAuth Apps](az-oauth-apps-phishing.md) +- [**Common Phishing**](https://book.hacktricks.wiki/en/generic-methodologies-and-resources/phishing-methodology/index.html) dla credentials lub przez [OAuth Apps](az-oauth-apps-phishing.md) - [**Device Code Authentication** Phishing](az-device-code-authentication-phishing.md) -## System plików Credentials +### Exchange Online direct-to-tenant SMTP spoofing -The **`az cli`** przechowuje wiele interesujących informacji w **`/.Azure`**: -- **`azureProfile.json`** zawiera informacje o użytkownikach zalogowanych w przeszłości -- **`clouds.config`** zawiera informacje o subskrypcjach -- **`service_principal_entries.json`** zawiera credentials aplikacji (tenant id, clients and secret) +Jeśli cel używa **Exchange Online / EOP**, ale jego publiczny **MX** wskazuje na **third-party mail gateway** (Mimecast, Proofpoint, Mailgun, on-prem filtering, etc.), sprawdź, czy Exchange Online nadal akceptuje mail wysłany **directly** do hosta tenant `*.mail.protection.outlook.com`. W takim przypadku attacker może **skip the external gateway** i wysłać phishing mail bezpośrednio do EOP. + +To jest przydatne do **initial access / phishing**, ponieważ dostarczenie może nadal się udać, nawet gdy spoofed sender nie przejdzie **SPF**, **DKIM** i **DMARC**. Dla internal senders Outlook może też rozpoznać spoofed sender jako prawdziwego employee, zwiększając trust. + +**Recon / triage:** +```bash +# If the MX already points to Microsoft, this specific path is usually not the issue +dig +short MX target.com + +# Typical vulnerable pattern: the MX points to a third-party filter +# 10 mxb.eu.mailgun.org. +``` +Bezpośredni host EOP to zazwyczaj nazwa `mail.protection.outlook.com` specyficzna dla tenant (na przykład `target-com.mail.protection.outlook.com`). Często można odzyskać wzorzec nazewnictwa tenant z publicznej enumeracji tenant/domain oraz odpowiedzi autodiscover związanych z Exchange. + +**Minimal PoC:** +```powershell +Send-MailMessage -SmtpServer target-com.mail.protection.outlook.com -To victim@target.com -From ceo@target.com -Subject "Urgent" -Body "Review the attached payment change" -BodyAsHTML +``` +**Signals walidacyjne:** +- Mail jest wysyłany do `*.mail.protection.outlook.com` zamiast do publicznego hosta MX. +- Wiadomość jest dostarczana, mimo że nagłówki pokazują błędy takie jak `spf=fail`, `dkim=none`, `dmarc=fail` lub `compauth=none`. +- Secure Partner connector zwykle odrzuca etap `RCPT TO` z `5.7.51 TenantInboundAttribution; Rejecting.` + +**Technical notes / defensive hunting:** +- **Enhanced Filtering for Connectors** pomaga Exchange poprawnie przypisać oryginalnego nadawcę, ale samo w sobie **nie jest** granicą, która blokuje direct-to-tenant delivery. +- Microsoft dokumentuje dwa praktyczne controls przy użyciu zewnętrznego MX przed Exchange Online: +- Utwórz **Partner inbound connector** z `SenderDomains *` oraz `RestrictDomainsToCertificate` lub `RestrictDomainsToIPAddresses`, aby tylko zatwierdzony gateway mógł dostarczać mail do tenant. +- Utwórz **priority 0 transport rule**, która quarantines inbound mail, chyba że sender IP należy do zatwierdzonych zakresów gateway **albo** `X-MS-Exchange-Organization-AuthAs` zawiera `Internal`. +- Szukaj maili, gdzie **Received** pokazuje `*.mail.protection.outlook.com` jako pierwszy Microsoft hop, ale sender-authentication headers nadal pokazują **SPF/DKIM/DMARC failures**. +- Jeśli target nadal pozwala na **Direct Send**, wyłączenie go głównie ogranicza **internal** sender spoofing; nie zastępuje to mitigation opartego o connector / transport-rule dla dowolnego **external** spoofing. + +## Filesystem Credentials + +**`az cli`** przechowuje dużo interesujących informacji w **`/.Azure`**: +- **`azureProfile.json`** zawiera info o zalogowanych użytkownikach z przeszłości +- **`clouds.config`** zawiera info o subscriptions +- **`service_principal_entries.json`** zawiera aplikacje **credentials** (tenant id, clients i secret) - **`msal_token_cache.json`** zawiera **access tokens and refresh tokens** -Zauważ, że w macOS i linux te pliki są **niechronione** i przechowywane w postaci jawnej. +Zwróć uwagę, że w macOS i linux te pliki są **unprotected** przechowywane w postaci clear text. -## Źródła +## References - [https://aadinternals.com/post/just-looking/](https://aadinternals.com/post/just-looking/) - [https://www.securesystems.de/blog/a-fresh-look-at-user-enumeration-in-microsoft-teams/](https://www.securesystems.de/blog/a-fresh-look-at-user-enumeration-in-microsoft-teams/) - [https://www.netspi.com/blog/technical-blog/cloud-penetration-testing/enumerating-azure-services/](https://www.netspi.com/blog/technical-blog/cloud-penetration-testing/enumerating-azure-services/) +- [https://labs.infoguard.ch/posts/ghost-sender/](https://labs.infoguard.ch/posts/ghost-sender/) +- [https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/manage-mail-flow-using-third-party-cloud](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/manage-mail-flow-using-third-party-cloud) +- [https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-policies-about](https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-policies-about) +- [https://techcommunity.microsoft.com/blog/exchange/direct-send-vs-sending-directly-to-an-exchange-online-tenant/4439865](https://techcommunity.microsoft.com/blog/exchange/direct-send-vs-sending-directly-to-an-exchange-online-tenant/4439865) {{#include ../../../banners/hacktricks-training.md}}