ntobjmanager-mcp

🛰️ NtObjectManager-MCP

ステートフルな Windows RPC 調査 MCP — 2024～2026 年の CVE 手法をワンクリックツールに

🌐 中国語版

---

NtObjectManager-MCP とは？

AI エージェントに Windows RPC の攻撃対象領域の調査への、ライブかつステートフルなアクセスを提供する Model Context Protocol サーバーです。James Forshaw の NtObjectManager（NtCoreLib）を基盤としています。

一般的な PowerShell MCP ではできない、これが存在する理由となった 3 つの機能：

1. ステートフルな RPC 接続 — 永続的な PowerShell エンジンにより、解析済みの RpcServer オブジェクトと 接続済みの RPC クライアント がツール呼び出しをまたいで維持されます。 rpc_connect を一度実行すれば、rpc_call を何度も実行できます（認証ハンドシェイク、コンテキストハンドルの チェーン、セッション変数が維持されます）。
2. 固定ツールとしての CVE 手法 — 2024～2026 年の公開調査で標準的に使われている探索ワークフローを、プロンプトエンジニアリングなしでワンクリックで実行できます。
3. ラボ VM 内でのステートフルな実行 — 同じ単一エンジンの原則をゲスト内にも適用します。rpc_vm_exec は、呼び出しごとに新しいシェルを起動するのではなく、単一の永続的なゲストランスペースを通じて、呼び出しをまたいで変数と接続済みの RPC クライアントを維持します（vmrun フォールバックでは stateful: false と報告されます）。

┌────────────────────────────────────────────────────────────────────┐
│  AI Agent (Claude Code / OpenCode / any MCP client)                │
│      │  MCP (stdio, 24 tools)                                      │
│      ▼                                                             │
│  server.py ── snippets.py (PS templates, @@TOKEN@@ + ps_str escape)│
│      │                                                             │
│      ▼                                                             │
│  ps_engine.py ── persistent powershell.exe (base64 + __MCP_DONE__) │
│      │            state: $RPCMCP = @{ Servers; Clients; vars }     │
│      ▼                                                             │
│  NtObjectManager / NtCoreLib  ──►  RPC runtime (ALPC / pipe / TCP) │
└────────────────────────────────────────────────────────────────────┘

ツール一覧（24）

コアのステートフルパイプライン

ツール	目的
rpc_parse(file, symbol_path?)	PE を解析して RPC サーバーを検出し、キャッシュします（キーは file_N）
rpc_state()	キャッシュ済みサーバーとライブセッション
rpc_get_interface(key)	プロシージャ、NDR パラメーター、コンテキストハンドル、厳密性
rpc_query_endpoints(ifid?, search_binding?, find_alpc_port?)	EPM クエリ（ローカル またはリモート）
rpc_running_servers(pid?/service?)	実行中のプロセス／サービスを列挙
rpc_connect(session, key, binding?, auth?)	クライアントを生成して 接続（ステートフル）
rpc_methods(session)	オペレーション番号の対応付けを含むシグネチャ
rpc_call(session, method, args_json, store_as?)	リフレクション呼び出し。{"__var__"} で保存済みオブジェクトを渡します
rpc_disconnect(session)	セッションを切断

VM ラボブリッジ（ステートフルなゲスト実行）

ツール	目的
rpc_vm_exec(ps, timeout?, vm?)	ラボ VM 内で PowerShell を実行します。状態は呼び出しをまたいで維持されます（永続的なゲストランスペース）
rpc_vm_start_listener(vm?)	永続的なゲスト HTTP エンジン（vm_listener.ps1）を配置／起動します

2024–2026 CVE 手法ツール

ツール	手法の出典
rpc_scan_context_handles(paths)	コンテキストハンドルの型混同 — CVE-2025-48815 のパターン（whereisk0shl 2026）
rpc_inventory(paths?, limit?)	攻撃対象領域のインベントリ作成 + EPM 照合 — MS-RPC-Fuzzer フェーズ 1（CVE-2025-26651）
rpc_fuzz(session, dry_run=True)	プリミティブのみを対象とするデフォルト値ファジングと、ok／denied／error による分類 — デフォルトではドライラン
rpc_find_hijackable()	停止中のサービスの未登録インターフェース — EPM ポイズニング／RPC-Racer（CVE-2025-49760/59200/59230）
rpc_etw_unreachable(duration, trigger_script?)	停止中のサーバーを呼び出すクライアント — PhantomRPC（Kaspersky 2026）、管理者権限が必要
rpc_interface_security(key)	ALPC SD／匿名 ACE 監査 — MS-NRPC の NULL セッション（SafeBreach/Securelist 2025）
rpc_decode_flags(flags)	RpcServerRegisterIf3 フラグのビットマスクをデコード
rpc_format_client(key)	生成された C# クライアントソースをエクスポート（オフラインの grep ワークフロー）
rpc_new_struct(session, type, store_as)	NDR 複合型をセッション変数として構築
rpc_alpc_squat(name, duration)	ALPC ポートの占有 + 接続のキャプチャ（競合検証プリミティブ）
rpc_accessible_tasks()	ユーザーが起動可能なタスク（Dark-Elevator チェーンの素材、CVE-2026-66804 のパターン）
rpc_vars / rpc_clear_cache	セッション変数とキャッシュの管理（追い出し上限 150）

すべてのツール呼び出しは output/mcp_audit.log に追記されます。

フィールドテスト済み（実機での完全なハンティングラウンド）

候補	結果
srvsvc.dll 98716d03… が HIGH として検出	XactSrv（XsOpenPrinter/XsClosePrinter/XsAddJob/XsScheduleJob）と特定 — プリンターハンドルの型は 1 種類のみ。実機プローブ：非管理者でも接続は成功しますが、XsOpenPrinter → ACCESS_DENIED（認可ゲートは機能しています）。スキャナーの誤検出モードを文書化済み
ssdpsrv.dll（CVE-2025-48815 のオリジナル）	20 個のコンテキストハンドルすべてが厳密 — 現行ビルドではパッチ適用済み
51 モジュールのスイープ	31 件の検出結果、HIGH が 6 件。すべて「1 つのプロデューサー → 多数のコンシューマー」。NDR レイヤーでは複数の型のハンドルを証明できません（リバースエンジニアリングが必要）
EPM ハイジャックの対象領域	インターフェースが未登録の停止中サービスが 10 個（AppIDSvc、ClipSVC、dcsvc など）
タスクチェーン	ユーザーが起動可能な SYSTEM タスクを 44 個インベントリ化
判定	テスト対象ホストで悪用可能と確認できる脆弱性はありません — 各手順の証拠付き

🚀 クイックスタート

# 1) Prerequisites (one-time)
Install-Module NtObjectManager -Scope CurrentUser -Force
pip install -r requirements.txt            # mcp>=1.2.0 (1.x / 2.x compatible)

# 2) Verify — three suites, all green
python tests\smoke_test.py                 # 17 checks (live MCP stdio round-trip)
python tests\var_test.py                   # 10 checks (store_as / __var__ mechanics)
python tests\audit.py                      # 43 checks (edge cases, hostile paths, concurrency)

# 3) Run the server
python server.py                           # stdio MCP

Claude Code:

claude mcp add ntobjectmanager-rpc -- python C:\path\to\ntobjmanager-mcp\server.py

任意の MCP クライアント（例：OpenCode の opencode.json）：

{
  "mcp": {
    "ntobjectmanager-rpc": {
      "type": "local",
      "command": ["python", "C:\\path\\to\\ntobjmanager-mcp\\server.py"],
      "enabled": true
    }
  }
}

例：コンテキストハンドルの型混同（CVE-2025-48815 のパターン）

1. rpc_parse  C:\Windows\System32\target.dll  [symbol_path optional]
2. rpc_scan_context_handles ["C:\\Windows\\System32\\target.dll"]
3. rpc_get_interface target_0                 → producer ([out] ctx) / consumer ([in] ctx) pairs
4. rpc_connect s1 target_0                    → auto-discovers binding via EPM
5. rpc_methods s1                            → opnum-mapped signatures
6. rpc_call s1 XsOpenPrinter-like args store_as="h"   → keep the raw handle object
7. rpc_call s1 XsClosePrinter-like [{"__var__":"h"}] → feed it to the other type

store_as / {"__var__"} はチェーンの中核となるプリミティブです。RPC の戻りオブジェクトは、シリアライズとデシリアライズを経ずに呼び出し間で受け渡されます。これは、プロデューサーからコンシューマーへのハンドル型混同テストにまさに必要なものです。

📁 プロジェクト構成

ntobjmanager-mcp/
├── server.py            # 24 MCP tools + audit logging wrapper
├── snippets.py          # PowerShell templates (@@TOKEN@@ render + ps_str escaping)
├── ps_engine.py         # Persistent engine: base64 cmds + __MCP_DONE__ markers, timeouts
├── wrapper.ps1          # PS-side loop (state lives in $RPCMCP)
├── vm_listener.ps1      # Persistent guest HTTP bridge (stateful VM exec)
├── tests/
│   ├── smoke_test.py    # 17 checks — live stdio end-to-end
│   ├── var_test.py      # 10 checks — store_as/__var__ object passing
│   ├── audit.py         # 43 checks — hostile inputs, concurrency, engine kill/restart
│   ├── hunt.py          # Full dogfood hunting round (safe policy)
│   ├── hunt2_static.py  # Deep-dive: symbols + producer/consumer map
│   ├── hunt2_wide.py    # 51-module sweep
│   └── hunt2_probe.py   # Safe runtime probes (exposure / task cross-ref)
├── ARCHITECTURE.md      # Engine protocol + design decisions
├── CHANGELOG.md         # Decision history (R1–R13)
├── SECURITY.md          # Authorized-use policy + MSRC disclosure
├── CONTRIBUTING.md      # Development invariants
└── LICENSE              # MIT

🛡️ 機能の境界について

主張	状況
ツール呼び出しをまたぐステートフルクライアント	はい — 永続エンジン + $RPCMCP
ラボ VM 内でのステートフル実行	はい — 永続的なゲストの実行環境が 1 つ（rpc_vm_exec）。vmrun フォールバックはステートレスです
コンテキストハンドルのチェーン（プロデューサー → コンシューマー）	はい — store_as / __var__ による生オブジェクトの受け渡し
型混同の自動確認	いいえ — NDR ではハンドルの型が異なることを証明できません。リバースエンジニアリングで確認してください（XactSrv の事例を参照）
完全な不正 RPC ホスティング	いいえ — NtObjectManager 2.0.1 にはサーバービルダーが含まれていません。rpc_alpc_squat が対応するのは競合のキャプチャのみです
ETW トレース／ALPC SDDL	管理者権限が必要です（logman／SeDebugPrivilege）
シンボル解決されたプロシージャ名	環境に依存します（symsrv チェーン）。それ以外の場合はヒューリスティックなフォールバック名を使用します
Windows PS 5.1 以外での実行	まだ未対応です（pwsh 7 は未テスト）

📖 ドキュメント

• ARCHITECTURE.md — エンジンプロトコル、状態モデル、設計上の決定事項
• CHANGELOG.md — PS 5.1 のマーシャリングに関する 2 件のバグを含む、R1～R13 の決定履歴
• SECURITY.md — 許可された使用方法、VM の分離、MSRC への報告
• CONTRIBUTING.md — 開発上の不変条件とテスト要件

⚠️ 免責事項

合法的なセキュリティ研究、教育、許可を得たテストのみを対象としています。 rpc_call は実際の RPC メソッドを呼び出すため、サービスがクラッシュする可能性があります。分離された VM で実行し、本番環境や日常使用するホストでは決して実行しないでください。このツールを通じて発見された脆弱性は、責任ある開示の手順（MSRC）に従って報告してください。

📄 ライセンス

MIT — Copyright (c) 2026 ntobjmanager-mcp Contributors