gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-07-28 14:47:17 -07:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['', 'src/pentesting-cloud/azure-security/az-unauthenticated-

Browse Source
This commit is contained in:
Translator
2026-06-16 13:29:13 +00:00
parent 02213e5603
commit abb244c573
1 changed files with 154 additions and 43 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/README.md
+154 -43
View File
@@ -2,21 +2,21 @@
{{#include ../../../banners/hacktricks-training.md}}
## Azure テナント
## Azure Tenant
### テナント列挙
### Tenant Enumeration
いくつかの**public Azure APIs**があり、**テナントのドメイン**を知っているだけで攻撃者はそれらにクエリを投げて追加情報を収集できます。\
APIを直接クエリすることも、PowerShellライブラリ[**AADInternals**](https://github.com/Gerenios/AADInternals)（`Install-Module AADInternals`）を使うこともできます:
**tenant の domain** さえ分かれば、その tenant についてより多くの情報を集めるために問い合わせできる、**public Azure APIs** がいくつかある。\
API に直接問い合わせることも、PowerShell library [**AADInternals**](https://github.com/Gerenios/AADInternals) (`Install-Module AADInternals`) を使うこともできる:
- **テナントIDを含むログイン情報**
- **tenant ID を含む login information**
- `Get-AADIntTenantID -Domain <domain>` (main API `login.microsoftonline.com/<domain>/.well-known/openid-configuration`)
- **テナント内の有効なすべてのドメイン**
- **tenant 内のすべての有効な doimains**
- `Get-AADIntTenantDomains -Domain <domain>` (main API `autodiscover-s.outlook.com/autodiscover/autodiscover.svc`)
- **ユーザーのログイン情報**。`NameSpaceType`が`Managed`であれば、EntraIDが使用されていることを意味します
- **user の login information**. `NameSpaceType` が `Managed` なら、EntraID が使われていることを意味する
- `Get-AADIntLoginInformation -UserName <UserName>` (main API `login.microsoftonline.com/GetUserRealm.srf?login=<UserName>`)
Azure テナントのすべての情報は[**AADInternals**](https://github.com/Gerenios/AADInternals)の**たった1つのコマンド**で取得できます:
[**AADInternals**](https://github.com/Gerenios/AADInternals) の **たった 1 つの command** で Azure tenant のすべての情報を問い合わせできる:
```bash
# Doesn't work in macos because 'Resolve-DnsName' doesn't exist
Invoke-AADIntReconAsOutsider -DomainName corp.onmicrosoft.com | Format-Table
@@ -35,33 +35,33 @@ company.mail.onmicrosoft.com True True True Managed
company.onmicrosoft.com True True True Managed
int.company.com False False False Managed
```
テナントの名前、ID、および「ブランド」名の詳細を確認できます。さらに、Desktop Single Sign-On (SSO)、別名 [**Seamless SSO**](https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sso) のステータスも表示されます。有効になっている場合、この機能はターゲット組織内に特定のユーザーが存在するかどうか（列挙）を判定するのに役立ちます。
テナントの名前、ID、そして「brand」名に関する詳細を確認できます。さらに、Desktop Single Sign-On (SSO)、別名 [**Seamless SSO**](https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sso) の状態も表示されます。有効な場合、この機能は対象組織内の特定ユーザーの存在（enumeration）を判定するのに役立ちます。
さらに、出力にはターゲットテナントに関連付けられたすべての検証済みドメイン名とそれぞれの identity type が表示されます。federated domains の場合、通常は ADFS サーバーである利用中の identity provider の FQDN も開示されます。"MX" 列はメールが Exchange Online にルーティングされているかを示し、"SPF" 列は Exchange Online がメール送信者としてリストされているかを示します。現在の reconnaissance 機能は SPF レコード内の "include" ステートメントを解析しないため、偽陰性が発生する可能性がある点に注意してください。
また、出力には対象テナントに関連付けられたすべての検証済みドメイン名と、それぞれの identity type が表示されます。federated domains の場合、使用中の identity provider の Fully Qualified Domain Name (FQDN)、通常は ADFS server も公開されます。「MX」列はメールが Exchange Online にルーティングされるかどうかを示し、「SPF」列は Exchange Online がメール送信者として列挙されていることを示します。なお、現在の reconnaissance 機能は SPF レコード内の「include」ステートメントを解析しないため、false negative が発生する可能性があります。
### ユーザー列挙
### User Enumeration
> [!TIP]
> テナントが同じユーザーに複数のメールアドレスを使用している場合でも、**ユーザー名は一意**であることに注意してください。これは、そのユーザーに関連付けられたドメインでのみ動作し、他のドメインでは動作しないことを意味します。
> たとえ tenant が同じユーザーに対して複数の email を使っていても、**username は一意**です。つまり、動作するのはユーザーが関連付けた domain に対してのみで、他の domains では動作しません。
テナント内に**ユーザー名が存在するかどうかを確認する**ことが可能です。これは**ゲストユーザー**も含み、ゲストのユーザー名は次の形式です：
tenant 内で **username が存在するか** を確認できます。これには **guest users** も含まれ、その username の形式は次のとおりです:
```
<email>#EXT#@<tenant name>.onmicrosoft.com
```
この email は、“@” がアンダースコア “\_” に置き換えられたユーザーのメールアドレスです。
メールはユーザーのメールアドレスで、`@` がアンダースコア `\_` に置き換えられています。
[**AADInternals**](https://github.com/Gerenios/AADInternals) を使うと、ユーザーが存在するかどうかを簡単に確認できます:
[**AADInternals**](https://github.com/Gerenios/AADInternals) を使えば、ユーザーが存在するかどうかを簡単に確認できます:
```bash
# Check does the user exist
Invoke-AADIntUserEnumerationAsOutsider -UserName "user@company.com"
```
ソースの README.md の内容がここに提供されていません。翻訳するテキスト（ファイル全体または該当部分）を貼り付けてください。長文の場合は対象のセクションを指定してください。
Azure での unauthenticated enum と initial entry に関する内容です。
```
UserName Exists
-------- ------
user@company.com True
```
1行に1つのメールアドレスを含むテキストファイルを使うこともできます:
また、1行に1つのメールアドレスが入ったテキストファイルも使用できます:
```
user@company.com
user2@company.com
@@ -75,22 +75,22 @@ external.user_outlook.com#EXT#@company.onmicrosoft.com
# Invoke user enumeration
Get-Content .\users.txt | Invoke-AADIntUserEnumerationAsOutsider -Method Normal
```
現在、選べる**4つの異なる列挙方法**があります。詳細は `Get-Help Invoke-AADIntUserEnumerationAsOutsider` を参照してください:
現在、選択できる **4つの異なる enumeration method** があります。`Get-Help Invoke-AADIntUserEnumerationAsOutsider` で情報を確認できます:
It supports following enumeration methods: Normal, Login, Autologon, and RST2.
次の enumeration method をサポートしています: Normal, Login, Autologon, and RST2.
- The **Normal** method seems currently work with all tenants. Previously it required Desktop SSO (aka Seamless SSO) to be enabled for at least one domain.
- **Normal** method は、現在はすべての tenant で動作するようです。以前は、少なくとも1つの domain で Desktop SSO (aka Seamless SSO) が有効になっている必要がありました。
- The **Login** method works with any tenant, but enumeration queries will be logged to Azure AD sign-in log as failed login events!
- **Login** method は任意の tenant で動作しますが、enumeration queries は failed login events として Azure AD sign-in log に記録されます!
- The **Autologon** method doesn't seem to work with all tenants anymore. Probably requires that DesktopSSO or directory sync is enabled.
- **Autologon** method は、もうすべての tenant では動作しないようです。おそらく、DesktopSSO か directory sync が有効である必要があります。
有効なユーザー名を特定した後、ユーザーの**情報を取得**できます:
有効な username を見つけた後は、次の方法で **user についての info** を取得できます:
```bash
Get-AADIntLoginInformation -UserName root@corp.onmicrosoft.com
```
スクリプト [**o365spray**](https://github.com/0xZDH/o365spray) は、**メールアドレスが有効かどうか**を判別することもできます。
スクリプト [**o365spray**](https://github.com/0xZDH/o365spray) も、**メールが有効かどうか** を確認できます。
```bash
git clone https://github.com/0xZDH/o365spray
cd o365spray
@@ -101,15 +101,15 @@ python3 ./o365spray.py --enum -d carloshacktricks.onmicrosoft.com -u carlos
# Check a list of emails
python3 ./o365spray.py --enum -d carloshacktricks.onmicrosoft.com -U /tmp/users.txt
```
**User Enumeration via Microsoft Teams**
**Microsoft Teams を介した User Enumeration**
もう一つの良い情報源は Microsoft Teams です。
もう1つの有用な情報源は Microsoft Teams です。
Microsoft Teams の API はユーザーの検索を可能にします。特に "user search" エンドポイント **externalsearchv3** と **searchUsers** は、Teams に登録されたユーザーアカウントに関する一般的な情報を取得するために利用できます。
Microsoft Teams の API ではユーザーを検索できます。特に "user search" エンドポイントの **externalsearchv3** と **searchUsers** を使うことで、Teams に登録された user accounts に関する一般情報を要求できます。
API レスポンスによって、存在しないユーザーと有効な Teams サブスクリプションを持つ既存のユーザーを区別することが可能です。
API のレスポンスによっては、存在しないユーザーと、有効な Teams subscription を持つ既存ユーザーを区別できます。
スクリプト [**TeamsEnum**](https://github.com/lucidra-security/TeamsEnum) は、与えられたユーザー名のセットを Teams API に対して検証するために使用できますが、使用するには Teams にアクセス権を持つユーザーへのアクセスが必要です。
スクリプト [**TeamsEnum**](https://github.com/lucidra-security/TeamsEnum) は、与えられた username のセットを Teams API に対して検証するために使えますが、使用には Teams access を持つユーザーへの access が必要です。
```bash
# Install
git clone https://github.com/lucidra-security/TeamsEnum
@@ -119,13 +119,45 @@ python3 -m pip install -r requirements.txt
# Login and ask for password
python3 ./TeamsEnum.py -a password -u <username> -f inputlist.txt -o teamsenum-output.json
```
翻訳するテキスト（README.md の内容）を貼ってください。受け取ったら指定のルールに従って翻訳します。
# Azure: unauthenticated enum and initial entry
Azure では、unauthenticated での enum と initial entry のためにいくつかの public surface を持っています。以下は、よくある入口です。
## 公開されている主な service
- `https://login.microsoftonline.com/`
- `https://management.azure.com/`
- `https://graph.microsoft.com/`
- `https://portal.azure.com/`
これらは auth を必要とせずにアクセスできることがありますが、実際の action は permission によって制限されます。
## 初期の enum
Azure tenant に対して最初に行うべき enum の一部は以下です。
- tenant の確認
- user / group の識別
- subscribed services の列挙
- exposed applications の確認
- misconfiguration の探索
## 役立つ endpoint
- `https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration`
- `https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration`
- `https://graph.microsoft.com/v1.0/`
- `https://graph.microsoft.com/beta/`
## 注意点
Azure は public に見える endpoint が多いですが、情報が見えることと実際に操作できることは別です。enum では、認可の境界を理解しながら進める必要があります。
```
[-] 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)
```
さらに、既存ユーザーの以下のような在席状況を列挙することが可能です:
さらに、次のような既存ユーザーの availability 情報を列挙することも可能です:
- Available
- Away
@@ -133,11 +165,53 @@ python3 ./TeamsEnum.py -a password -u <username> -f inputlist.txt -o teamsenum-o
- Busy
- Offline
もし**不在時メッセージ**が設定されている場合、TeamsEnum を使用してそのメッセージを取得することもできます。出力ファイルが指定されている場合、不在時メッセージは自動的に JSON ファイルに保存されます:
**out-of-office message** が設定されている場合、TeamsEnum を使ってその message を取得することも可能です。出力ファイルが指定されている場合、out-of-office messages は自動的に JSON file 内に保存されます:
```
jq . teamsenum-output.json
```
翻訳するソースが提供されていません。src/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/README.md の内容をここに貼ってください。
---
title: Azure - Unauthenticated Enumeration and Initial Entry
description: Azure - Unauthenticated Enumeration and Initial Entry
---
# Azure - Unauthenticated Enumeration and Initial Entry
In this section we are going to enumerate Azure resources and discover ways of initial access without valid credentials.
## Unauthenticated Enumeration
After signing into Azure, you can enumerate the accessible resources and find initial access points via the GUI or the CLI.
### Via GUI
You can find an accessible tenant following a few simple steps:
1. Login to the Azure Portal at [https://portal.azure.com/](https://portal.azure.com/) or use the search engine you prefer to find the organization you're targeting.
2. Browse the directories available to your account and identify the target.
3. Once inside the target directory, go to Azure Active Directory.
4. Look for tenants that might be publicly accessible.
5. Explore any accessible resources to find exposed data, configurations, or leaks.
6. Use the portal's search and filtering features to identify services or assets that might be weakly secured or misconfigured.
By using the GUI, you can uncover exposed data and misconfigurations that may reveal opportunities for initial access.
### Via CLI
You can perform unauthenticated enumeration against certain Azure endpoints using the CLI or HTTP requests, depending on what is exposed.
For example, some services may allow anonymous access to metadata or configuration endpoints, which can be queried to gather information about the environment.
## Initial Entry
Once you've identified exposed resources or misconfigurations, you can look for paths to initial entry such as:
- Weak or default credentials
- Publicly exposed storage or secrets
- Misconfigured application settings
- Overly permissive access controls
- Leaked tokens or connection strings
If you find a valid initial access point, you can proceed with further assessment and post-exploitation steps as appropriate.
```json
{
"email": "user2@domain",
@@ -192,10 +266,10 @@ jq . teamsenum-output.json
az-password-spraying.md
{{#endref}}
## Azure Services が使用するドメイン
## domains を使用する Azure Services
It's also possible to try to find **Azure services exposed** in common azure subdomains like the ones documented in this [post:
](https://www.netspi.com/blog/technical-blog/cloud-penetration-testing/enumerating-azure-services/)
[この post:
](https://www.netspi.com/blog/technical-blog/cloud-penetration-testing/enumerating-azure-services/) に記載されているような一般的な azure のサブドメインで、**公開されている Azure Services** を見つけることも可能です。
- App Services: `azurewebsites.net`
- App Services – Management: `scm.azurewebsites.net`
@@ -216,7 +290,7 @@ It's also possible to try to find **Azure services exposed** in common azure sub
- Search Appliance: `search.windows.net`
- API Services: `azure-api.net`
You can use a method from [**MicroBust**](https://github.com/NetSPI/MicroBurst) for such goal. This function will search the base domain name (and a few permutations) in several **azure domains:**
この目的のために [**MicroBust**](https://github.com/NetSPI/MicroBurst) の method を使えます。この function はベースドメイン名（およびいくつかの permutation）を複数の **azure domains:** で検索します。
```bash
Import-Module .\MicroBurst\MicroBurst.psm1 -Verbose
Invoke-EnumerateAzureSubDomains -Base corp -Verbose
@@ -226,15 +300,48 @@ Invoke-EnumerateAzureSubDomains -Base corp -Verbose
- [**Common Phishing**](https://book.hacktricks.wiki/en/generic-methodologies-and-resources/phishing-methodology/index.html) for credentials or via [OAuth Apps](az-oauth-apps-phishing.md)
- [**Device Code Authentication** Phishing](az-device-code-authentication-phishing.md)
### Exchange Online direct-to-tenant SMTP spoofing
もし対象が **Exchange Online / EOP** を使用しているが、公開 **MX** が **third-party mail gateway**（Mimecast, Proofpoint, Mailgun, on-prem filtering など）を指している場合、Exchange Online がテナントホスト `*.mail.protection.outlook.com` に**直接**送られたメールをまだ受け入れるか確認する。そうであれば、攻撃者は **external gateway** を**バイパス**して、phishing mail をそのまま EOP に送信できる。
これは **initial access / phishing** に有用で、spoofed sender が **SPF**、**DKIM**、**DMARC** に失敗しても配信できる可能性があるためである。内部送信者の場合、Outlook は spoofed sender を実在する社員として解決することもあり、信頼性が増す。
**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.
```
直接のEOPホストは、通常 tenant-specific な `mail.protection.outlook.com` 名です（例えば `target-com.mail.protection.outlook.com`）。tenant の命名パターンは、public tenant/domain enumeration や Exchange 関連の autodiscover レスポンスからしばしば復元できます。
**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
```
**Validation signals:**
- Mail は `*.mail.protection.outlook.com` に送信され、public MX host ではありません。
- ヘッダに `spf=fail`, `dkim=none`, `dmarc=fail`, `compauth=none` などの失敗が表示されていても、メッセージは配信されます。
- Secure な Partner connector は通常、`RCPT TO` ステージで `5.7.51 TenantInboundAttribution; Rejecting.` を返して拒否します。
**Technical notes / defensive hunting:**
- **Enhanced Filtering for Connectors** は Exchange が元の sender を正しく属性付けするのに役立ちますが、単独では direct-to-tenant delivery をブロックする境界ではありません。
- Microsoft は、Exchange Online の前段に external MX を使う場合の実用的な control を 2 つ文書化しています:
- **Partner inbound connector** を `SenderDomains *` と `RestrictDomainsToCertificate` または `RestrictDomainsToIPAddresses` で作成し、承認された gateway だけが tenant に配信できるようにします。
- **priority 0 transport rule** を作成し、sender IP が承認済み gateway ranges に含まれるか **または** `X-MS-Exchange-Organization-AuthAs` に `Internal` が含まれる場合を除き、inbound mail を quarantine します。
- **Received** で `*.mail.protection.outlook.com` が最初の Microsoft hop として表示されているのに、sender-authentication headers では依然として **SPF/DKIM/DMARC failures** が示される mail を hunt します。
- target がまだ **Direct Send** を許可している場合、それを無効化すると主に **internal** sender spoofing の低減になりますが、任意の **external** spoofing に対する connector / transport-rule mitigation の代替にはなりません。
## Filesystem Credentials
The **`az cli`** は **`<HOME>/.Azure`** の中に多くの興味深い情報を格納します:
- **`azureProfile.json`** は過去にログインしたユーザーに関する情報を含みます
- **`clouds.config`** はサブスクリプションに関する情報を含みます
- **`service_principal_entries.json`** はアプリケーションの **credentials** (tenant id, clients and secret) を含みます
- **`msal_token_cache.json`** は **access tokens and refresh tokens** を含みます
**`az cli`** は **`<HOME>/.Azure`** の中に多くの興味深い情報を保存します:
- **`azureProfile.json`** には過去にログインした users の情報が含まれます
- **`clouds.config`** には subscriptions の情報が含まれます
- **`service_principal_entries.json`** には applications の **credentials** (tenant id, clients and secret) が含まれます
- **`msal_token_cache.json`** には **access tokens and refresh tokens** が含まれます
Note that in macOS and linux these files are **unprotected** stored in clear text.
macOS と linux では、これらの files は **unprotected** で、clear text のまま保存されていることに注意してください。
@@ -243,5 +350,9 @@ Note that in macOS and linux these files are **unprotected** stored in clear tex
- [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}}