RemoteMonolog：NTLM認証強制のためのDCOMの武器化

Mimikatzを使用して、楽に認証情報を取得できた時代は、良くも悪くも終わりを告げようとしています。Microsoftが認証情報の盗難やエンドポイントの検知と対応（EDR）ソリューションに対する防御を強化する中、横移動、ペイロードの実行、ローカル・セキュリティー機関サブシステム・サービス（LSASS）への直接アクセスなど、従来のレッドチームの手法に対するセキュリティが高められています。その結果、レッド・チームのコミュニティーは、Windowsシステム上の認証情報を収集するための代替方法を模索する必要に迫られてきました。

「高度な」ペイロードを必要とせず、LSASSにアクセスすることなく、「リビング・オフ・ザ・ランランド」で、十分に活用されていないコンポーネント・オブジェクト・モデル（COM）オブジェクトを活用するだけで、同等の結果を達成できることを想像してみてください。興味をそそられた人は、ぜひご覧ください。このブログには、次の取り組みで使える楽しいトリックが満載です。

COMとその分散型対応ツールであるDistributed Component Object Model(DCOM)の基本を簡単に解説し、RunAs設定と認証強制がなぜ影響力を持つのかを掘り下げ、新しい認証情報「 RemoteMonologue」のコンポーネントツールを紹介します。

コンポーネント・オブジェクト・モデル（COM）は、Windowsで最も古くから浸透しているテクノロジーのひとつであり、日常的なアプリケーションやサービスの裏側でひっそりと動作しています。COMは、古くなっているにもかかわらず、攻撃者にとって貴重なリソースであり続け、横移動、特権エスカレーション、永続化を実現する別の方法を提供しています。しかし、その固有の複雑さによって、攻撃対象領域の多くは十分に調査されていません。

このブログで、理解すべき重要な概念は以下のとおりです。

• COM：ソフトウェア・コンポーネントがプロセスの境界を越えて相互に通信できるようにするWindowsのコア・テクノロジー。COMを使用すると、プログラムは機能を複製することなく、他のプログラムの機能を再利用できます。例えば、あるプログラムでは、COMオブジェクトを使用してシステム・ログを読み取ったり、Excelファイルに新しいエントリーを追加したりすることができます。その際、プログラム自体は主要な機能を実装しません。
• 分散コンポーネントオブジェクトモデル(DCOM)は、ネットワークベースの通信を可能にするCOMの拡張です。DCOMを使用すると、あるマシンで実行されるプロセスが、別のマシンにあるCOMオブジェクトの関数を呼び出すことができます。このネットワークベースの機能により、DCOMは横移動の貴重なツールとなっています。DCOMオブジェクトにアクセスするには、通常、リモートシステム上のローカル管理者権限が必要です。

大まかには、COMオブジェクトが、次の2つの主要コンポーネントを持つ自己完結型のユニットになったものを想像してください。

• プロパティ： これらはオブジェクトの状態または構成を表します。
• メソッド： これらは、オブジェクトが実行できるアクションを表します。例えば、COMオブジェクトには、プロセスを起動したり、ファイルを作成したり、認証リクエストを開始したりするメソッドがある場合があります。

攻撃者はこれらの方法を悪用して横移動を促進し、後で説明するようにパスワード・クラッキングやリレー攻撃のためにリモートNTLM認証を強制することができます。

面白いことに飛び込む前に、COMの重要なコンポーネントの1つについてさらに詳しく説明する必要があります。COMにおけるアプリケーション識別子(AppID)は、特にDCOMや特定のセキュリティコンテキストを必要とするアプリケーションにおいて、COMアプリケーションのセキュリティ、アイデンティティ、ランタイムの挙動を管理するための重要な仕組みとして機能します。COMクラスがあるAppIDで登録されると、そのAppIDに定義されたセキュリティー設定を継承します。

特に注目されるセキュリティ設定は RunAs キーで、これはインスタンス化時にDCOMオブジェクトを実行するユーザーアカウントを指定します。RunAsキーは、次のレジストリにあります。

• HKEY_CLASSES_ROOT\AppID\{AppID_GUID}

DCOMとRunAsキーに関するMicrosoftのドキュメンテーションをレビューしていたところ、Interactive Userという特定の値が目に留まりました。この値により、現在システムのコンソール・セッションにログインしているユーザーのセキュリティー・コンテキストでDCOMオブジェクトが実行されるように設定されます。攻撃的な観点から見ると、これは興味深いことです。なぜなら、影響を受けるユーザーの認証情報を知らなくても、DCOMオブジェクトを活用して別のユーザーとして操作できる可能性があるからです。

AppIDを持つすべてのDCOMオブジェクトで、RunAs値がInteractive Userに設定されているわけではありません。実際、AppIDの約半数にはRunAs値がまったく設定されていません。しかし、目的に合わせてRunAsの値を追加または変更できるとしたらどうでしょうか。

デフォルトでは、レジストリ内のAppIDは随意アクセス制御リスト（DACL）で保護され、TrustedInstallerの所有者特権が付与され、ローカル管理者は読み取り専用アクセスに制限されます（図1を参照）。

ただし、ローカル管理者にはSeTakeOwnershipPrivilege特権が付与されます。これで、レジストリ・キーを含むシステム・オブジェクトの所有権を取得できるようになります。この権限は、AppIDの所有権を変更できるため、この攻撃に関連しています。所有権を変更すると、AppIDに対するフル・コントロール権限が獲得できるので、その後その設定を変更してRunAs値を追加または変更できます。

RunAs値をInteractive Userに変更すると、攻撃は簡単になります。これにより、別のアクティブなセッションのコンテキストでDCOMオブジェクトを強制的に実行できます。ただし、この攻撃が成功するかどうかは、最終的には、ターゲットとなる特定のDCOMオブジェクトによって公開されるプロパティとメソッドに依存します。

DCOMオブジェクトをセッション・ハイジャック・ツールに変換できることがわかったので、次のステップは、ハイジャックを完了するためにどのメソッドとプロパティーを活用できるかを特定することです。この研究では、ペイロードを実行することなくユーザーの侵害を達成できるかどうかを探りました。これは、一般に公開されているDCOMの横移動の技術とは異なるアプローチです

ここでは、「ファイルレス」形式で同等の成果を達成することに重点を置きました。つまり、ターゲット・システム上でペイロードを転送または実行する必要がないということです。この違いが重要なのは、ターゲット・システム上でのペイロードの転送と実行は、Red Teamのオペレーションにおいて「コストがかかる」アクションとみなされることが多いからです。このステップを回避することで、一般的なセキュリティコントロールがトリガーされるリスクが大幅に軽減されます。そのため、DCOM経由でNTLM認証を強制することで、リモート・ユーザー・アカウントを侵害することを目指しました。

従来の横移動を実行するのではなく、NTLM認証を強制することには、いくつかの主要なメリットがあります。

• NTLMv1/NTLMv2ハッシュをキャプチャし、オフラインで解読する
• NTLMv1またはWebDAV NTLMv2ハッシュをLDAPやSMBなどの他のネットワーク・サービスに中継して、影響を受けるユーザーとしてアクションを実行する
• 通常、セキュリティー・ツールの監視を強化させることになる、ターゲット・システム上でのペイロードの転送と実行を回避する
• LSASSプロセスへの接触を避け、検知リスクを軽減する

この記事を書いている時点では、ほとんどのドメイン・コントローラーでは、LDAP署名とチャネル・バインディングは、デフォルトで必要なく、強制されていません。これらの主要な機能は、Windows Server 2025でのみ必須です。つまり、ターゲット・システムからNTLMv1またはWebDAV認証を強制できた場合、それをLDAPに中継し、影響を受けるユーザーとしてアクションを実行できます。同様に、Windowsサーバーでは、ドメイン・コントローラーを除き、デフォルトではSMB署名は必要ありません。

もう一つの重要な考慮点は、NTLMv1のハッシュはレインボー・テーブルを用いて簡単にクラックできるということで、レインボー・テーブルは 2024 年 12 月の時点で、Nic Losbyによって公に共有されています。これらのテーブルにより、NTLMv1ハッシュから NTLM認証情報を回復するのに必要な時間と労力が大幅に削減されます。NTLMv2ハッシュの代わりにNTLMv1ハッシュを取得するには、ターゲットシステムの次のレジストリキーを変更します。

• HKLM\System\CurrentControlSet\Control\Lsa\LmCompatibilityLevel

LmCompatibilityLevelを2以下の値に設定すると、システムは認証のためにNTLMv1にフォールバックします。この変更はローカル管理者権限で可能であり、一般に「NetNTLMv1ダウングレード攻撃」と呼ばれます。

あるいは、HTTPベースの認証はこのサービスに転送できるため、WebDAV認証をキャプチャしてLDAPに中継することもできます。WebClientサービスがまだ特権アクセスで実行されていない場合は、リモートによりターゲットシステム上で有効にできます。有効にすると、UNCパスにマシンのNetBIOS名を指定することで、我々のリスナーに対するWebDAV NTLM認証を強制できます。例：

• \\MYHACKERBOX@80\giveme\creds.txt

NTLMリレー攻撃と、さまざまなエンドポイントに中継できるプロトコルの詳細については、参考情報をこちらで参照してください。

私はこの調査中に、CLSID {03837546-098B-11D8-9414-505054503030}を含むDCOMオブジェクトServerDataCollectorSetを分析して、認証強制に利用できるメソッドとプロパティーを特定しました。際立ったプロパティの1つはDataManager・であり、幸いなことに、このCOMオブジェクトには、そのメソッドとプロパティを詳細に定義するタイプ・ライブラリが含まれていました。

OleView.NETを使ってServerDataCollectorSetのタイプ・ライブラリをレビューしたところ、DataManagerプロパティに2つのパラメータを想定しているExtractメソッドがあることを発見しました。

1. CabFilename – 抽出するCABファイルの名前。
2. DestinationPath – CABファイルの内容を抽出するパス。

CabFilenameパラメーターの存在は、ネットワーク認証アクションにつながる可能性のあるUNCパスが提供される可能性を示唆していたので、特に興味深いものでした。

この理論をテストするために、自分のシステム（172.22.164.58）を指すUNCパスをCabFilenameパラメーターに指定し、図4に示されているように Responderを実行しました。その結果、成功したのです！図5に示すように、NTLMv2ハッシュをキャプチャすることができました。

次に、 ServerDataCollectorSetのRunAs キーを変更して、リモート・システム（172.22.166.170） 上の別のユーザーから認証情報をキャプチャーできるかどうかをテストしました。これを実現するために、リモート・レジストリサービスを使って、AppID{03837503-098B-11D8-9414-505054503030}に、Interactive User値を追加しました。

別のユーザーがターゲット・システム（この場合はGALAXY\yoda）にログインしたら、GALAXY\AdministratorとしてServerDataCollectorSet DCOM オブジェクトにアクセスし、図 6 と同じExtractメソッドを実行しました。もう一度、認証を正常に取得できました。今回は、図7に示すように、GALAXY\yodaからのものです。これは、RunAsキーをInteractive Userに変更することで、DCOMオブジェクトを利用して他のユーザーのセッションをハイジャックできることを示しています。

この攻撃の流れを以下の図に示します。

認証強制の影響を受けやすいもう1つの興味深い DCOM オブジェクトは、CLSID {2C941FC5-975B-59BE-A960-9A2A262853A5}を持つFileSystemImageです。このオブジェクトは、メソッドを呼び出すのではなくプロパティを変更するだけで強制がトリガーされるため、特にユニークです。この手法は、DCOMベースの攻撃ではあまり一般的ではありません。

問題のプロパティはWorkingDirectory です。これは、デフォルトでは対話型ユーザーの%TEMP%フォルダーを指します。ただし、図9および10に示すように、WorkingDirectoryの値をリスナーを指すUNCパスに変更することで、NTLMv2認証を取得することができます。

このセッション・ハイジャック機能を検証するために、AppID {2C941FD1-975B-59BE-A960-9A2A262853A5}のRunAsキーをInteractive Userに設定してリモートでテストしました。この構成により、FileSystemImage DCOMオブジェクトがトリガーされ、ターゲット・システム上のアクティブなユーザーのセキュリティー・コンテキストの下で実行されました。そして期待どおり、そのユーザーのNTLMv2ハッシュをキャプチャすることができました。

この手法は、プロパティとメソッドを変更することで認証強制が実現でき、それによってDCOMオブジェクトの潜在的な攻撃対象領域が拡大することを実証しています。

共有する価値のある最後のDCOMオブジェクトは、CLSIDが{4CB43D7F-7EEE-4906-8698-60DA1C38F2FE}のUpdateSessionです。タイプ・ライブラリをレビューしたところ、AddScanPackageServiceメソッドが目に留まりました。これは、serviceName引数と、さらに興味深いことにscanFileLocation引数を必要としていたからです。scanFileLocationの存在は、UNCパスを受け入れる可能性があることを示唆しています。

この理論をテストした際、NTLMv2認証の取得に成功しましたが、以下に示すように、ユーザー・アカウントの認証情報ではなくマシン・アカウントの認証情報を受け取りました。

この結果は、RunAsキーを追加してInteractive Userに設定した後でも、 UpdateSession DCOMオブジェクトがマシン・アカウントとしてオペレーションを実行したため、特に興味深いものになっています。では、なぜこれが起こるのでしょうか？その簡単な答えは、DCOMオブジェクト自体はインスタンス化または対話型ユーザーのセキュリティー・コンテキストの下で実行される一方で、ネットワークオペレーションは別のプロセスであるsvchost.exeによって実行されるということです。UNCパスはsvchost.exeに渡されますが、これらのオペレーションには常にSYSTEMアカウントがデフォルトとして使用されます。したがって、RunAsキーの設定はこの動作には影響しません。

RunAsキーはネットワーク・オペレーションに使用されるアカウントに影響を与えませんが、マシンアカウントの認証情報の取得は、次のようないくつかの攻撃シナリオでは依然として価値があります。

1. Active Directory内の興味深いDACL権限へのアクセス ：
   マシン・アカウント（例：DOMAIN\MACHINE$ ）は、Active Directory内の特定のオブジェクトに対する権限を持つ可能性があり、横移動や権限昇格に役立つ可能性があります。
2. 追加回避のためのシルバー・チケットの偽造：
   マシン・アカウントのNTLMハッシュを使用してシルバー・チケットを偽造し、システム上の任意のユーザーになりすまして、検知のリスクを低減しながらアクションを実行することができます。

この攻撃は 「RemoteMonologue」と呼ばれ、 InternalMonologueと似た機能を持ち、重要な違いは遠隔攻撃を行うことです。このツールは Impacket ライブラリを用いてPythonで開発され、攻撃プロセスを自動化します。

RemoteMonogueは、前述の3つのDCOMオブジェクト（-dcom）のいずれかをターゲットにし、指定されたリスナー（-auth-to）に対して認証強制を実行する機能を提供します。さらに、複数のシステム全体で資格情報を検証するための散布モジュール（-spray）が含まれており、認証情報を取得するという追加の利点もあります。このツールは、NetNTLMv1のダウングレード攻撃（-downgrade）もサポートしており、WebClientサービスがHTTP認証を促進するオプション（-webclient）を備えています。最後に、このツールには、ターゲット・システム上のアクティブ・セッションを持つユーザーを列挙するためのクエリー・モジュール（-query）が含まれています。

以下は、Responderをリスナーとして使用しながら、NetNTLMv1ダウングレード攻撃でRemoteMonologueを実行する例です。DCOMオプションが指定されていない場合、デフォルトでこのツールはServerDataCollectorSet DCOMオブジェクトを使用します。

以下に別の例を示します。今回は、FileSystemImage DCOMオブジェクトを用いて攻撃を実行し、WebClientサービスがHTTP認証を取得できるようにし、取得結果をntlmrelayxでLDAPに中継します。

このブログで説明している手法から保護し、検知するためには、いくつかの防止および検知対策を実施できます。

予防措置:

1. LDAP署名とチャネル・バインディングを有効にする： ドメイン・コントローラーにLDAP署名の実施とチャネル・バインディングを設定して、LDAPエンドポイントをリレー攻撃から保護します。注： これらの設定は、Windows Server 2025以降、デフォルトで適用されます。
2. 最新のWindowsバージョンへのアップグレード： サーバーをWindows Server 2025に、ワークステーションをWindows 11バージョン24H2にアップグレードして、NetNTLMダウングレード攻撃を軽減します。れらのバージョンではNTLMv1が削除されているためです。
3. SMB署名を強制する：Windowsサーバー上でSMB署名を有効化および強制し、SMBリレー攻撃を防ぎます。
4. 強力なパスワード・ポリシーを実装する： 強力なパスワード要件を適用して、パスワード・クラッキング攻撃をより困難にします。

検知の機会：

1. DCOMオブジェクトへのリモートアクセスを監視する：影響を受けるDCOMオブジェクトとその特定のプロパティとメソッドへのアクセスを追跡して、異常なアクティビティを特定します。
2. レジストリーの変更を監視する： RunAsおよびLmCompatibilityLevelレジストリー・キーの変更を監視します。
3. WebClientサービス・アクティビティの追跡： WebClientサービスがリモートで有効化されているインスタンスを監視します。これはHTTPベースのNTLM認証を容易にするために使用されるものです。

RemoteMonogue攻撃は、十分に活用されていないDCOMオブジェクトを武器化し、ファイルレスで認証強制攻撃を実行する方法を明らかにしています。攻撃者は、特定のプロパティを変更し、NetNTLMv1のダウングレードなどの技術を活用することで、ペイロードをデプロイしたり、LSASSなどの機密プロセスに直接アクセスしたりすることなく、ユーザー・アカウントを侵害し、権限を昇格させることができます。

LDAP署名やSMB署名の実施、NTLMv1などのレガシー・プロトコルの無効化など、主要なシステムの強化に注力することで、防御側は攻撃対象領域を大幅に縮小できます。さらに、レジストリの変更、DCOMアクティビティ、リモートサービスの変更を強力に監視することで、これらの手法を初期段階で検知し、影響を軽減することができます。