MagicWeb: NOBELIUM の妥協後のトリックで誰でも認証

2022 年 8 月 26 日更新: イベント ID 501 を検索するために AD FS イベントログの収集を有効にする手順を追加し、Microsoft Sentinel に AD FS 監査ログの新しいリソースを追加しました。

Microsoft のセキュリティ研究者は、MagicWeb と呼ばれる侵害後の機能を発見しました。これは、侵害された環境への永続的なアクセスを維持するために、NOBELIUM として追跡している攻撃者によって使用されます。 NOBELIUM は引き続き非常に活発に活動しており、米国、ヨーロッパ、中央アジアの政府機関、非政府組織 (NGO)、政府間組織 (IGO)、およびシンクタンクを対象とした複数のキャンペーンを並行して実行しています。 Microsoft Threat Intelligence Center (MSTIC) は、MagicWeb が進行中の侵害中に展開された可能性が高く、エビクションを先取りできる戦略的修復手順中にアクセスを維持するために NOBELIUM によって利用された可能性があると評価しています。

NOBELIUM は永続性を維持する方法として ID と資格情報アクセスの悪用を使用しており、MagicWeb のような特殊な機能は攻撃者にとって目新しいものではありません。Microsoft は 2021 年 9 月に、MagicWeb と同様の方法と意図を持つFoggyWebという名前のエクスプロイト後の機能を公開しました。 FoggyWeb は、侵害された AD FS サーバーの構成データベースを盗み出し、トークン署名証明書とトークン復号化証明書を復号化し、追加のマルウェアコンポーネントをダウンロードして実行することができました。 MagicWeb は、密かに直接アクセスできるようにすることで、FoggyWeb の収集機能を超えています。 MagicWeb は、Active Directory Federated Services (AD FS) サーバーによって生成されたトークンで渡されたクレームの操作を可能にする悪意のある DLL です。 Golden SAML のような攻撃で使用される署名証明書ではなく、認証に使用されるユーザー認証証明書を操作します。

NOBELIUM は、最初に高度な特権資格情報へのアクセスを取得し、横方向に移動して AD FS システムへの管理者権限を取得することで、MagicWeb を展開することができました。これはサプライチェーン攻撃ではありません。攻撃者は AD FS システムへの管理者アクセス権を持っており、正当な DLL を独自の悪意のある DLL に置き換え、正当なバイナリではなく AD FS によってマルウェアが読み込まれるようにしました。バックドアは、進行中のインシデント対応調査中に、MSTIC および Microsoft 365 Defender Research と連携して、Microsoft の検出および対応チーム (DART) によって発見されました。 Microsoft は、クライアントからの同意を得てこの情報を共有しています。この調査の時点で、MagicWeb は高度に標的にされているようです。

ドメインコントローラーと同様に、AD FS サーバーはユーザーを認証できるため、同じ高レベルのセキュリティで処理する必要があります。お客様は、 AD FS 強化ガイダンスを含む総合的なセキュリティ戦略を実装することで、MagicWeb やその他のバックドアから防御できます。この特定の発見の場合、MagicWeb は、独自の検出および防御シナリオを提示する、はるかに大きな侵入チェーンの 1 つのステップです。

AD FS などのすべての重要なインフラストラクチャでは、攻撃者が管理アクセスを取得しないようにすることが重要です。攻撃者が管理アクセス権を取得すると、さらなるシステム侵害、アクティビティの難読化、永続化のための多くのオプションが与えられます。このようなインフラストラクチャは分離し、専用の管理者アカウントのみがアクセスできるようにし、定期的に変更を監視することをお勧めします。この攻撃やその他の攻撃を防ぐことができるその他のセキュリティ対策には、横方向の移動を防ぐための資格情報の衛生が含まれます。 AD FS はオンプレミスサーバーであり、すべてのオンプレミスサーバーと同様に、展開が古くなったり、パッチが適用されなかったりする可能性があり、ローカル環境の侵害や横方向の移動によって影響を受ける可能性があります。これらの理由から、フェデレーション認証用のAzure Active Directory などのクラウドベースの ID ソリューションへの移行は、それが提供する堅牢なセキュリティのために推奨されます。詳細については、以下の軽減セクションを参照してください。この機能は限定的に使用されると評価していますが、Microsoft は、他のアクターが同様の方法論を採用する可能性があると予想しているため、このブログで提供されている強化と緩和のガイダンスを確認することをお勧めします。

Table of contents

MagicWeb が認証を覆す仕組み
この脅威を軽減する方法
高度なハンティングクエリ
検出
1. Microsoft Defender ウイルス対策
2. エンドポイントの Microsoft Defender
侵害の痕跡 (IOC)
MagicWebのテクニカル分析
参考文献

MagicWeb が認証を覆す仕組み

MagicWeb は侵害後のマルウェアであり、環境への高度な特権アクセスを取得し、AD FS サーバーに横方向に移動した後、攻撃者によってのみ展開できます。 AD FS サーバー上の任意のユーザーアカウントの認証を検証することで、環境への永続的なアクセスを維持するという目標を達成するために、NOBELIUM は、AD FS 操作で使用される正当なMicrosoft.IdentityServer.Diagnostics.dllファイルをコピーして、バックドア DLL を作成しました。このファイルの正当なバージョンは、Microsoft によって署名されたカタログであり、通常、デバッグ機能を提供するために起動時に AD FS サーバーによって読み込まれます。 NOBELIUM のバックドアバージョンのファイルは署名されていません。 AD FS サーバーへのアクセスを許可する攻撃者の高度な特権アクセスは、環境内で任意の数のアクションを実行できた可能性があることを意味しますが、操作中の永続化と情報の盗難という目標を容易にするために、AD FS サーバーをターゲットにすることを明確に選択しました。 .

特権の昇格とラテラルムーブメントによって AD FS サーバーへの管理アクセスを取得した後、 C:WindowsAD FSMicrosoft.IdentityServerを編集することで、NOBELIUM の悪意のあるMicrosoft.IdentityServer.Diagnostics.dllを AD FS プロセスに読み込むことができます。 Servicehost.exe.configを使用して別のパブリックトークンを指定します。これは、開始時に AD FS プロセスに読み込まれるものを制御します。 AD FS は .NET アプリケーションであるため、構成ファイルで指定された DLL をグローバルアセンブリキャッシュ(GAC) から読み込みます。構成内のトークンを変更することで、攻撃者は AD FS に悪意のある DLL を読み込むように指示しました。 MagicWeb によるクレームの傍受と操作により、アクターはトークンを生成できます。このトークンにより、敵対者は AD FS ポリシー (ロールポリシー、デバイスポリシー、およびネットワークポリシー) をバイパスし、多要素認証 (MFA) を含む任意のクレームを持つ任意のユーザーとしてサインインできます。 .

構成ファイルのセクションのスクリーンショット。 — 図 1. *C:WindowsAD FSMicrosoft.IdentityServer.Servicehost.exe.config*が*Microsoft.IdentityServer.Diagnostics.dll*を読み込むように設定されている

PublicKeyToken が部分的に編集された構成ファイルのセクションのスクリーンショット。 — 図 2. NOBELIUM は、正規の*Microsoft.IdentityServer.Diagnostics.dll*とは異なるパブリックトークンを使用し、AD FS に GAC で別のファイルを探すように指示します。

MagicWeb の悪意のある PublicKeyToken (部分的に編集) と正当なものを示す構成ファイルの部分的なスクリーンショット。 — 図 3. *Microsoft.IdentityServer.Servicehost.exe.config*のクローズアップ。MagicWeb の悪意のある*PublicKeyToken*と正規バージョンの DLL の*PublicKeyToken*を比較

Microsoft.IdentityServer.Diagnostics を表示している Windows ファイルエクスプローラーのスクリーンショット。ディレクトリに 2 つのフォルダがあります。悪意のあるファイルに関連するフォルダー名は部分的に編集されています。 — 図 4. MagicWeb に感染したサーバー上の GAC 内のディレクトリ。悪意のある*Microsoft.IdentityServer.Diagnostics.dll*ファイルと正当なファイルが別のディレクトリにある

NOBELIUM が MagicWeb マルウェアを使用して AD FS プロセスを破壊する方法を理解するには、AD FS クレームがどのように機能するかを理解することが重要です。 AD FS は、単一のセキュリティまたはエンタープライズ境界内で利用可能なシングルサインオン機能をインターネットに接続するアプリケーションに使用する機能を拡張し、組織の Web ベースのアプリケーションにアクセスしながら、顧客、パートナー、およびサプライヤーに合理化されたユーザーエクスペリエンスを提供します。 AD FS は、クレームベースの認証に依存して、ユーザーの ID と承認クレームを検証します。これらのクレームは、認証に使用できるトークンにパッケージ化されます。 MagicWeb は、クレームプロセスに自身を挿入して、AD FS サーバーの通常の役割以外で悪意のあるアクションを実行します。

AD FS クレームの仕組みを要約したアイコンと矢印を含む図。 — 図 5. AD FS クレームパイプラインがフェデレーションアプリケーションに入るユーザーに対してトークンを発行する方法

Security Assertion Markup Language (SAML) は、x509 証明書を使用して、ID プロバイダーとサービス間の信頼関係を確立し、トークンに署名および復号化します。これらの x509 証明書には、証明書を使用するアプリケーションを指定する拡張キー使用法 (EKU) 値が含まれています。たとえば、1.3.6.1.4.1.311.20.2.2 のオブジェクト識別子 (OID) 値を含む EKU は、スマートカードログオンの使用を許可します。組織はカスタム OID を作成して、証明書の使用をさらに絞り込むことができます。

MagicWeb の認証バイパスは、指定されたユーザープリンシパル名の認証要求中に、MagicWeb マルウェアでハードコーディングされた非標準の拡張キー使用法 OID を渡すことによって発生します。この一意のハードコードされた OID 値が検出されると、MagicWeb は、認証要求がすべての標準 AD FS プロセス (MFA のチェックを含む) をバイパスし、ユーザーの要求を検証するようにします。 MagicWeb は、Golden SAML のような攻撃で使用される SAML クレームの署名証明書ではなく、SAML サインインで使用されるユーザー認証証明書を操作しています。

OID が部分的に編集されたユーザー証明書の [詳細] タブのスクリーンショット。 — 図 6. MagicWeb が受け入れたユーザー証明書の例。「Unknown Key Usage」の下で強調表示されている数字は、MagicWeb にハードコードされた 2 つの OID のうちの 1 つです。

ユーザー証明書の [認証パス] タブのスクリーンショット。 — 図 7. ユーザー証明書チェーンの例。無効なデジタル署名を示していますが、認証には引き続き機能します。

NOBELIUM はターゲットごとに固有のトレードクラフトを使用するため、OID と公開トークンもターゲットごとに固有である可能性が高くなります。このレポートでは、これらの OID とトークンを編集しました。この攻撃に関連する亜種を探す方法については、ハンティングガイダンスのセクションを参照してください。

この脅威を軽減する方法

NOBELIUM が MagicWeb を展開できるかどうかは、AD FS サーバーへの管理アクセス権を持つ高度な特権資格情報にアクセスできるかどうかにかかっていました。これにより、アクセスできるシステムで、必要な悪意のあるアクティビティを実行できるようになりました。

AD FS サーバーをTier 0資産として扱い、ドメインコントローラーやその他の重要なセキュリティインフラストラクチャに適用するのと同じ保護で保護することが重要です。 AD FS サーバーは、構成された証明書利用者に認証を提供するため、AD FS サーバーへの管理アクセス権を取得した攻撃者は、構成された証明書利用者 (AD FS サーバーを使用するように構成された Azure AD テナントを含む) に対する認証を完全に制御できます。資格情報の衛生状態を実践することは、高度な特権を持つ管理者アカウントを保護し、公開を防止するために重要です。これは特に、ログオン制限などの制御機能を備えたワークステーションなど、侵害されやすいシステムに当てはまり、Windows ファイアウォールなどの制御機能を備えたこれらのシステムへの横移動を防止します。

Azure Active Directory (Azure AD) 認証への移行は、オンプレミスの侵害が認証サーバーに横方向に移動するリスクを軽減するために推奨されます。お客様は、移行に関する次の参考資料を使用できます。

高度なハンティングクエリ

マイクロソフトセンチネル

ADFS の詳細モードログを有効にしている Microsoft Sentinel のお客様は、次のクエリを使用して疑わしい OID を探すことができます: https://github.com/Azure/Azure-Sentinel/tree/master/Detections/SecurityEvent/ADFSAbnormalEnhancedKeyUsageAttribute-OID.yaml 。

注: 正しいイベントコレクションを使用して、Sentinel で適切なコネクタを有効にすることが重要です。 Sentinel での AD FS 監査ログ収集の詳細については、この投稿を参照してください。

GAC で署名されていないファイルを検索する

正規のMicrosoft.IdentityServer.Diagnostics.dllは、Microsoft によって署名されたカタログです。カタログ署名は、 Windows がAuthenticodeとは異なるコードの整合性を検証するために使用する方法であり、署名されたコードのみを実行するランタイム強制ではなく、オフライン検証に使用されます。このファイルのカタログ署名は、ファイルプロパティペイン、およびファイル整合性チェッカー、セキュリティツール、およびオンラインマルウェアリポジトリで、ファイルが署名されていないように見えることを意味します。以下のスクリプトを使用すると、署名されていないバイナリを探して、カタログ署名付きバイナリと Authenticode 署名付きバイナリの両方を理解できます。

Microsoft 365 Defender を使用して GAC で署名されていない DLL を表示する

このクエリは、過去 60 日以内に作成された GAC フォルダー内の署名されていない DLL を表示します。

DeviceImageLoadEvents

     | |ここで、FolderPath は @"C:WindowsMicrosoft.NETassemblyGAC_MSILMicrosoft.IdentityServer" です。およびファイル名が「.dll」で終わり、not(isempty(SHA1))

     | | SHA1 で kind = leftanti (DeviceFileCertificateInfo) に参加

     | |個別の DeviceName、FolderPath、FileName、SHA1、SHA256

PowerShell を使用して GAC で Microsoft 以外の署名付き DLL を列挙する

以下は、関連する GAC フォルダー内の Microsoft 以外の署名付き DLL を列挙するために使用できるスクリプトの例です。ここで、 servers.txtはスキャンするサーバーのリストです。正当なMicrosoft.IdentityServer.Diagnostics.dllはカタログ署名されているため、ファイルプロパティを表示するときに署名は表示されませんが、PowerShell のクエリと DLL の読み込みでは表示されます。

$servers = get-content -Path (ファイルへのパス)servers.txt 
Foreach ($servers の $server) { 
Write-Output "処理サーバー: $server" 
Invoke-Command -ComputerName $server {Get-ChildItem -Filter "*.dll" -Recurse "C:WindowsMicrosoft.NETassemblyGAC_MSIL" | get-authenticodesignature |フィート} 
}

検出

Microsoft Defender ウイルス対策

Microsoft Defender ウイルス対策は、次のマルウェア名でこの脅威を検出します。

トロイの木馬:MSIL/MagicWeb.A!dha

エンドポイントの Microsoft Defender

Microsoft Defender for Endpoint のお客様には、攻撃の可能性を示す次のアラートが表示される場合があります。

ADFS 永続バックドアが検出されました

侵害の痕跡 (IOC)

現時点では、Microsoft はこの NOBELIUM アクティビティに関する IOC を共有していません。ただし、NOBELIUM は、キャンペーンごとにインフラストラクチャと機能を頻繁にカスタマイズし、キャンペーン固有の属性が発見された場合の運用上のリスクを最小限に抑えます。お使いの環境で MagicWeb が識別された場合、SHA-256 値などの他のターゲットからの静的 IOC と一致する可能性はほとんどありません。環境を調査するには、上記のハンティングガイダンスを使用することをお勧めします。

MagicWebのテクニカル分析

NOBELIUM は、 Microsoft.IdentityServer.Diagnostics名前空間/型から TraceLog クラスに悪意のあるコードを追加することで、正当なMicrosoft.IdentityServer.Diagnostics.dllを変更しました。

正当なMicrosoft.IdentityServer.Diagnostics.dllの TraceLog クラスのヘッダーセクションを以下に示します。

一方、NOBELIUM のバックドアバージョンのMicrosoft.IdentityServer.Diagnostics.dllの TraceLog クラスのヘッダーセクションを以下に示します。

TraceLog() クラスが強調表示された構成ファイルのセクションのスクリーンショット。 — 図 9. NOBELIUM のバックドアバージョンの*Microsoft.IdentityServer.Diagnostics.dll*からの*Microsoft.IdentityServer.Diagnostics*名前空間の TraceLog クラスのヘッダーセクション

上記のコードのバックドアバージョンでは、NOBELIUM は TraceLog クラスの静的コンストラクターを追加しています。静的コンストラクターは、静的データを初期化するため、または一度だけ実行する必要がある特定のアクションを実行するために使用されます。最初のインスタンスが作成される前、または静的メンバーが参照される前に、自動的に呼び出されます。

悪意のある静的コンストラクターは、TraceLog クラスの最初のインスタンスが作成される前に 1 回実行されます。 TraceLog クラスの新しいインスタンスがこの DLL のさまざまな場所に作成されることを考えると、DLL が初めて読み込まれるとすぐ (AD FS サーバーの起動時)、悪意のある静的コンストラクターの実行が確実に行われます。上記のMicrosoft.IdentityServer.Servicehost.exe.configへの悪意のある変更の後)。

NOBELIUM の悪意のある静的コンストラクタには、 AuthLogという名前のクラスからのInitialize()メソッドへの参照が含まれています。

Initialize() メソッドが強調表示された構成ファイルのセクションのスクリーンショット。 — 図 10. 悪意のある静的コンストラクター内の*AuthLog*という名前のクラスからの*Initialize()*メソッドへの参照

AuthLogクラスは、NOBELIUM によって DLL に追加されたまったく新しい悪意のあるクラスです。

上記のように、 Initialize()メソッドはRuntimeHelperという名前のクラスを参照します。これは、アクターによって DLL に追加されたさらに別のクラスです。 RuntimeHelperクラスとそのOverloadMethod()メソッドの主な目的は、実行時に正当な AD FS 関連メソッドをフックすることです。正当な AD FS メソッドをフックすることで、バックドアは正当なメソッドへの呼び出しを傍受し、代わりに独自のカスタムメソッドを呼び出すことができます。

上のスクリーンショットは、次の正当な AD FS メソッドが MagicWeb によってフックされていることを示しています。

ターゲットアセンブリ/DLL	ターゲットの種類	フックするターゲットメソッド	悪意のあるフック方式 (アクターが導入)
Microsoft.IdentityServer.IdentityModel.dll	Microsoft.IdentityModel.X509CertificateChain	建てる	構築開始
Microsoft.IdentityServer.WebHost.dll	Microsoft.IdentityServer.WebHost.WrappedHttpListenerRequest	GetClientCertificate	BeginGetClientCertificate
Microsoft.IdentityServer.WebHost.dll	Microsoft.IdentityServer.WebHost.Proxy.ProxyConfigurationData	エンドポイント構成	BeginEndpointConfiguration
Microsoft.IdentityServer.Service.dll	Microsoft.IdentityServer.Service.IssuancePipeline.PolicyEngine	ProcessClaims	BeginProcessClaims

フックメソッド: BeginBuild()

MagicWeb のBeginBuild()メソッドは、正当なターゲットメソッドBuild() ( Microsoft.IdentityServer.IdentityModel.dllから) をフックするために使用されます。

BeginBuild()メソッドは、最初に MagicWeb のヘルパーメソッドValidateX509Extensions() を呼び出します。

ヘルパーメソッドValidateX509Extensions()が true を返す場合、 BeginBuild()は true を返します。

ValidateX509Extensions()が false を返す場合、またはValidateX509Extensions()の呼び出しによって例外がスローされた場合、 BeginBuild()はMicrosoft.IdentityServer.IdentityModel.dllから正規のBuild()メソッドによって返された値を呼び出して返します。

これは、正当なMicrosoft.IdentityServer.IdentityModel.dllからの正当なターゲットメソッドBuild()が証明書を検査/構築する機会を得る前に、MagicWeb のフックメソッドが最初に証明書を検査し、ヘルパーメソッドValidateX509Extensions()が true を返す場合に true を返すことを意味します。 .

これにより、攻撃者は、正当なBuild()メソッドが呼び出される前に呼び出されるカスタム証明書検査/ビルドメソッドを導入することで、通常の証明書検査/ビルドプロセスを覆すことができます。

ヘルパーメソッド: ValidateX509Extensions()

MagicWeb のヘルパーメソッドValidateX509Extensions()は、 BeginBuild()およびその他のメソッドによって呼び出されます。

部分的に編集されたハッシュ値を含む構成ファイルのセクションのスクリーンショット。 — 図 13. ヘルパーメソッド*ValidateX509Extensions()*

ValidateX509Extensions()は、メソッドに渡された X509 証明書が null であるか、Microsoft 暗号化 API 証明書のコンテキストハンドル/ポインターが設定されていない場合に false を返します。

次に、メソッドは、メソッドに渡された X509 証明書の拡張機能を列挙します。列挙された拡張機能のタイプがX509EnhancedKeyUsageExtensionである場合、メソッドは拡張機能の OID を繰り返し処理し、各 OID の MD5 ハッシュを計算します (.NET MD5クラスを活用するカスタムハッシュ計算ヘルパーメソッドComputeHash()を使用)。

OID の MD5 ハッシュ値が次の 2 つのハードコードされた MD5 値のいずれかと一致する場合、メソッドは true を返します (この方法は、以下の 2 つの OID 値のいずれかが拡張機能に存在するかどうかを確認するために使用されます)。

67F5BD28A842A1C9[編集済] (OID値1.3.6.1.4.1.311.21.8.868518.12957973.4869258.12250419.[編集済].[編集済].[編集済].[編集済]に対応するMD5ハッシュ値)
6E3466296D2F63D[編集済] (OID 値1.3.6.1.4.1.311.21.8.868518.12957973.4869258.12250419.[編集済].[編集済].[編集済].[編集済]に対応する MD5 ハッシュ値)

OID 値が存在しない場合、メソッドは false を返します。

メソッドに渡された証明書に上記の 2 つのマジック OID 値のいずれかが含まれている場合、このヘルパーメソッドは true を返します。

フックメソッド: BeginGetClientCertificate()

クライアントの X509 証明書を取得するために、このメソッドはまずMicrosoft.IdentityServer.WebHost.dllから正当なGetClientCertificate()メソッドを呼び出します。次に、フックメソッドはヘルパーメソッドValidateX509Extensions()を呼び出して、クライアント証明書に 2 つの「魔法の」OID 値のいずれかが含まれているかどうかを判断します。クライアント証明書に 2 つの OID 値のいずれかが含まれている場合、フックメソッドは次のようになります。

現在のオブジェクトから_adapterフィールドを取得します
_adapterオブジェクトから_requestフィールドを取得します
( _requestオブジェクトからの) m_ClientCertificateErrorフィールドの値を 0 に設定します。

これは、正当なメソッドGetClientCertificate() ( Microsoft.IdentityServer.WebHost.dllから) がm_ClientCertificateErrorフィールドに設定する値に関係なく、クライアント証明書にマジック OID 値のいずれかが含まれている場合、フックメソッドはm_ClientCertificateErrorフィールドを上書きまたは設定することを意味します。 0.

この手法を使用することで、フックメソッドはアプリケーションの通常の動作に影響を与え、無効なクライアント証明書を有効な証明書として処理または受け入れるように見えます。

フックメソッド: BeginProcessClaims()

フックメソッドは、最初にAuthLogクラスのProcessClaims()メソッドを呼び出して、正規のProcessClaims()メソッドを間接的に呼び出します。

図 16 の 198 行目で、フックメソッドは MagicWeb のヘルパーメソッドGetClaims()を呼び出し、正当なProcessClaims()メソッドを呼び出して返された処理済みID オブジェクトを渡します。

上記のように、 GetClaims()メソッドは ID オブジェクトをパラメーターとして受け入れます。次に、このメソッドは、 type 、 type2 、および type3 という名前の 3 つの変数を、 types という名前の RuntimeHelperの静的フィールド/配列から取得した値で初期化します。

タイプフィールドには次の値が含まれます。

上記のassemblyByName2変数には、正当なアセンブリMicrosoft.IdentityServer.IdentityModel.dllを表すアセンブリオブジェクトが含まれています (まだ読み込まれていない場合、 RuntimeHelperクラスはアセンブリを現在のアプリケーションドメインに読み込みます)。 GetType()メソッドを呼び出すことにより、 RunHelperは型フィールド/配列のメンバーをMicrosoft.IdentityServer.IdentityModel.dllアセンブリの .NET 型で初期化します。

GetClaims()メソッドとtype 、 type2 、およびtype3の初期化に戻ると、変数type 、 type2 、およびtype3は、 Microsoft.IdentityServer.IdentityModel.dllからの次の型オブジェクトで初期化されます。

型: Microsoft.IdentityModel.Claims.IClaimsIdentity型オブジェクト
type2: Microsoft.IdentityModel.Claims.ClaimCollection型オブジェクト
type3: Microsoft.IdentityModel.Claims.Claim型オブジェクト

次に、 GetClaims()メソッドは、 Microsoft.IdentityModel.Claims.IclaimsIdentity ID オブジェクトのClaimsプロパティを取得します。また、 Claimsプロパティに存在する ( Microsoft.IdentityModel.Claims.ClaimCollection型の) クレームの数も取得します。

図 19. Claims プロパティを取得するGetClaims()

次に、 GetClaims()は ( Microsoft.IdentityModel.Claims.Claim型の) クレームを列挙し、各クレームと対応するクレームの種類を含む文字列を取得します。

上記のように、クレーム文字列とクレームタイプ文字列は list という名前のリストに格納されます。次に、このクレームのリストとそれに対応するクレームタイプがGetClaims()メソッドの呼び出し元である BeginProcessClaims( )に返されます。

BeginProcessClaims() メソッドに戻ると、 GetClaims()メソッドを使用してクレームを取得した後、フックメソッドBeginProcessClaims()がクレームリストを検索して、クレームタイプがhttp://schemas.microsoft.com/claims/のクレームが存在するかどうかを調べます。認証方法参照:

図 21. 特定のクレームのクレームリストを検索するBeginProcessClaims()

上記の 198 行目に示されているように、タイプhttp://schemas.microsoft.com/claims/authnmethodsreferencesのクレーム (存在する場合) は、 list という名前のリストに格納されます。タイプhttp://schemas.microsoft.com/claims/authnmethodsreferencesのクレームが存在し、その値がhttp://schemas.microsoft.com/claims/multipleauthnに設定されている場合、フックメソッドは、正当なメソッドによって返されたIclaimsIdentityオブジェクトを返します。フックメソッドの 191 行目のターゲットメソッドProcessClaims() ( Microsoft.IdentityServer.Service.dllから)。

この動作により、MFA が既に満たされている場合、フックメソッドは単にパススルーメソッドとして機能し、クレーム処理パイプラインの通常の動作には影響しません。

タイプhttp://schemas.microsoft.com/claims/authnmethodsreferencesのクレームが存在しないか、その値がhttp://schemas.microsoft.com/claims/multipleauthnに設定されていない場合、フックメソッドは追加のチェックを実行します。未処理のクレーム (つまり、フックメソッドに渡された未処理の ID オブジェクトIDに含まれるクレーム)。ここでも、フックメソッドはGetClaims()ヘルパーメソッドを呼び出してクレームのリストを取得します。前述のように、正規のProcessClaims()メソッド (191 行目の結果変数に格納されている) を呼び出して返された処理された ID オブジェクトを使用してGetClaims()ヘルパーメソッドを呼び出す代わりに、フックメソッドは、フックメソッドに渡される未処理の ID オブジェクトID :

図 22. GetClaims()を呼び出すフックメソッド

204 行目で、フックメソッドは各クレームの値を列挙し、 ComputeHash()ヘルパーメソッドを使用して、(未処理の ID オブジェクトから) 各クレーム値の MD5 ハッシュ値を計算します。次に、いずれかのクレームの MD5 値が MD5 ハッシュ値6E3466296D2F63DE[REDACTED]と等しいかどうかを確認します。このハッシュ値は、 oidMFAHashesという名前のハードコードされたハッシュリストの唯一の要素です (つまり、このリストを拡張して、対象の他のハッシュ値を含めることができます)。

206 行目の MD5 ハッシュ値が6E3466296D2F63DE[REDACTED]の値を持つクレームがない場合、このメソッドは、( Microsoft.IdentityServer.Service.dllからの) 正当なターゲットメソッドProcessClaims()によって返された処理済みの ID オブジェクトを単純に返します。フックメソッドの191行目。前述のように、ハッシュ値6E3466296D2F63DE[編集済み]は OID 値1.3.6.1.4.1.311.21.8.868518.12957973.4869258.12250419.[編集済み].[編集済み].[編集済み].[編集済み] に対応します。

したがって、フックメソッドはクレームを列挙し、値が1.3.6.1.4.1.311.21.8.868518.12957973.4869258.12250419.[編集済み].[編集済み].[編集済み].[編集済み]のクレームがクレームに存在しない場合リストでは、フックメソッドは単にパススルーメソッドとして機能し、クレーム処理パイプラインの通常の動作には影響しません。

実行サイクルのこの時点までにフックメソッドがまだ返されていない場合、クレームの 1 つに OID 値1.3.6.1.4.1.311.21.8.868518.12957973.4869258.12250419.[編集済み].[編集済み].[が含まれていることを意味します。 [編集済み].[編集済み] (そうでない場合、上記の段落で説明したロジックによれば、フックメソッドは返されます)。

クレームの 1 つに OID 値1.3.6.1.4.1.311.21.8.868518.12957973.4869258.12250419.[編集済み].[編集済み].[編集済み].[編集済み]が含まれていることの確認に進み、フックメソッドは次のセクションに進みます。は、クレームインジェクションを実行するという MagicWeb の主な目的を表しています。

クレーム挿入プロセスを担当するコードを説明する前に、リストとクレーム変数に既に格納されているものを再確認することが重要です。

list : 前述のように、フックメソッドは正当なメソッドProcessClaims()を呼び出して、着信 ID オブジェクトを処理します。次に、処理された ID オブジェクト (行 191 の結果に格納されている) がGetClaims()ヘルパーメソッドに渡され、処理された ID オブジェクトから抽出された要求の種類と値のペアのリストが取得されます (行 198)。クレームの種類と値のペアを取得した後、 http://schemas.microsoft.com/claims/authnmethodsreferences型のクレーム (存在する場合) がl istという名前のリストに格納されます (198 行目)。

claim : 前述のように、この変数は、未処理の ID オブジェクトから抽出されたクレームの種類と値のペアのリストを格納するために使用されます。

図 26.クレーム変数

この情報を念頭に置いて (およびクレームの 1 つに OID 値1.3.6.1.4.1.311.21.8.868518.12957973.4869258.12250419. [編集済み] . [編集済み] . [編集済み] . [編集済み] が含まれているという事実)、一度繰り返しますが、クレームインジェクションコードの最初の部分は次のとおりです。

特定の行が強調表示された構成ファイルのセクションのスクリーンショット。 — 図 27. クレーム挿入コードの一部

上記のように、 listが空の場合 (つまり、処理された ID オブジェクトにhttp://schemas.microsoft.com/claims/authnmethodsreferences型の要求の型と値のペアが含まれていなかった場合)、フックメソッドは代わりに要求に変わります (未処理の ID オブジェクトから抽出されたすべての要求の種類と値のペアのリスト) を取得し、要求の一覧でhttp://schemas.microsoft.com/claims/authnmethodsreferences型の要求の種類と値のペアを検索します。クレームリストにhttp://schemas.microsoft.com/claims/authnmethodsreferencesタイプのクレームタイプと値のペアが 1 つ以上含まれている場合、フックメソッドはクレーム情報を使用して、タイプhttp://schemas.microsoftの同一のクレームを追加します。 .com/claims/authnmethods処理された ID オブジェクトへの参照 (上記の 213 行目)。

このメソッドを使用して、ID オブジェクトを正当なProcessClaims()メソッドに渡した後、タイプhttp://schemas.microsoft.com/claims/authnmethodsreferencesのクレームが正当なメソッドによって返されない場合、フックメソッドは不正なクレームを手動で追加します。タイプhttp://schemas.microsoft.com/claims/authnmethodsの、フックされた正当なメソッドProcessClaims()の呼び出し元に返されるクレームのリストへの参照。

上記のように、不正なクレームをクレームのリストに追加するために、フックメソッドはAddClaim()という名前のヘルパーメソッドを呼び出します。

ヘルパーメソッドGetClaims()のコードと同様に、 AddClaims()は次の型オブジェクトで 2 つの変数を初期化します。

type : Microsoft.IdentityModel.Claims.IClaimsIdentity型オブジェクト
type2 : Microsoft.IdentityModel.Claims.ClaimCollectionタイプオブジェクト

235 行目で、 AddClaims()は型Microsoft.IdentityModel.Claims.Claimのコンストラクターを取得し、コンストラクターを呼び出して ( AddClaim()の呼び出し元から要求の型と値を渡します)、新しいClaimオブジェクトをインスタンス化します。

図 29. Microsoft.IdentityModel.Claims.Claimからの正当な内部コンストラクター

Microsoft.IdentityModel.Claims.Claimから取得され、 AddClaim()によって呼び出される正当な内部コンストラクターは、次のメソッドパラメーターを使用して内部コンストラクターClaim (オーバーロードされたメソッド) を呼び出します。

新しいClaimオブジェクトをインスタンス化した後、 AddClaim()はMicrosoft.IdentityModel.Claims.ClaimCollection型のAdd()メソッドを使用して、呼び出し元によってAddClaim()に渡された ID オブジェクトに新しい要求を追加します (この場合、新しい要求正当なメソッドProcessClaims()への呼び出しによって返されるクレームのリストを含むIDオブジェクトに追加されます)。

フックメソッドBeginProcessClaims()のクレームインジェクションコードを再検討します (そして、クレームの 1 つに OID 値1.3.6.1.4.1.311.21.8.868518.12957973.4869258.12250419.[編集済み].[編集済み].[編集済み]が含まれているという事実を思い出してください)。 ].[編集済] )、クレームインジェクションコードの 2 番目の部分は次のとおりです。

リストには、処理された ID オブジェクトから抽出されたタイプhttp://schemas.microsoft.com/claims/authnmethodsreferencesのクレームタイプと値のペアが含まれていることを思い出してください。リスト内のどのクレームにも値http://schemas.microsoft.com/claims/multipleauthnがない場合、フックメソッドはAddClaim()の呼び出しに進み、タイプhttp://schemas.microsoft.com/の不正なクレームを追加します。 claim/authnmethodsreferencesと value http://schemas.microsoft.com/claims/multipleauthnを、フックされた正当なメソッドProcessClaims()の呼び出し元に返されるクレームのリストに追加します。

Magic OID 値が1.3.6.1.4.1.311.21.8.868518.12957973.4869258.12250419. [編集済] . [編集済] . [編集済] . [編集済み]が AD FS に提示されます。正当なフックメソッドProcessClaims()がクレームを処理する方法に関係なく、 BeginProcessClaims()フック関数は、値http://schemas.microsoft.com/claims/multipleauthnを持つクレームが返されることを保証します。正当なフックメソッドProcessClaims()の呼び出し元に。

フック方法: BeginEndpointConfiguration()

バックドアBeginEndpointConfiguration()メソッドは、( Microsoft.IdentityServer.WebHost.dllからの) 正当なターゲットメソッドEndpointConfiguration()をフックするために使用されます。

enumType 変数は、 Microsoft.IdentityServer.WebHost.Proxy.CertificateValidation型オブジェクトであるRuntimeHelper.types[0]で初期化されます。 PropertyInfo変数propertyInfo 、 propertyInfo2 、およびpropertyInfo3は、 RuntimeHelperの「プロパティ」フィールド/配列から取得されたプロパティオブジェクトで初期化されます。

propertyInfo : Microsoft.IdentityServer.WebHost.dllのMicrosoft.IdentityServer.WebHost.Proxy.ProxyEndpoint型のCertificateValidationプロパティ
propertyInfo2 : Microsoft.IdentityServer.WebHost.dllのMicrosoft.IdentityServer.WebHost.Proxy.ProxyEndpoint型からのパスプロパティ
propertyInfo3: Microsoft.IdentityServer.WebHost.dllのMicrosoft.IdentityServer.WebHost.Proxy.ProxyEndpointConfiguration型の Endpoints プロパティ

次に、フックメソッドは、正当なEndpointConfiguration()メソッドが呼び出された値オブジェクトのEndpointプロパティの値を取得します。 Endpointプロパティは、 ProxyEndpointオブジェクトのコレクションを保持します。フックメソッドはProxyEndpointオブジェクトを列挙し、オブジェクトごとに、 CertificateValidation列挙の値が「 SSL 」を表す「1」に設定されているかどうかを確認します。 ProxyEndpointオブジェクトのCertificateValidation列挙が ‘1’/’SSL’ に設定されている場合、165 行目で、フックメソッドはCertificateValidation列挙の値を ‘0’ で上書きします。これは、’None’ を意味します。変更が確実に反映されるように、フックメソッドは値オブジェクトのEndpointプロパティを、上書きされたCertificateValidation列挙値 (つまり、「None」で上書きされた「SSL」) を含む更新されたEndpointプロパティで上書きします。

真のフックメソッドとして動作し、179 行目で、このメソッドは正当なEndpointConfiguration()メソッドを呼び出しますが、’value’ オブジェクトが変更されています。したがって、AD FS の通常の操作中に正当なEndpointConfiguration()メソッドが呼び出されると、このフックメソッドは呼び出しをインターセプトし、呼び出された正当なEndpointConfiguration()メソッドにオブジェクトを渡す前に、各ProxyEndpointのCertificateValidation値を上書きします。オブジェクトを呼び出してから、正当なEndpointConfiguration()メソッドを呼び出しますが、 CertificateValidation値が変更され、’SSL’ から ‘None’ に変更されました。

CertificationValidation値を ‘None’ (‘SSL’ の場合) に上書きする目的は、WAP が特定の悪意のある証明書を含む要求を AD FS に渡して、さらなる認証処理を行えるようにすることです。 Microsoft.IdentityServer.ProxyService/TLSClientReqeustHandlerによると、 CertificateValidationが ‘1’ (‘SSL’) で、検証中にクライアント証明書にエラーがある場合、WAP はクライアントから AD FS への現在の要求の送信を停止します。

参考文献

「I am AD FS and so can you: Attacking Active Directory Federated Services」、Austin Baker および Douglas Bienstock、Troopers 2019
Active Directory フェデレーションサービスの主要な概念について、Microsoft のドキュメント

参照: https://www.microsoft.com/en-us/security/blog/2022/08/24/magicweb-nobeliums-post-compromise-trick-to-authenticate-as-anyone/

MagicWeb: NOBELIUM の妥協後のトリックで誰でも認証

MagicWeb が認証を覆す仕組み

この脅威を軽減する方法

高度なハンティングクエリ