Ntobjmanager Mcp

io.github.lupingQAQ由 GitHub 账号 lupingQAQ 发布v1.0.0更新于 Oct 24, 2026

Stateful Windows RPC attack-surface research for AI agents: 22 tools on NtObjectManager.

已验证STDIO仅桌面开发者工具安全与监控

概览

AI 生成的概览

一个仅限 Windows 的 MCP 服务器，通过 NtObjectManager 为 AI 助手提供有状态的 Windows RPC 攻击面研究工具。

可以做什么
解析 PE 文件中的 RPC 服务器，查看接口、端点和运行中的服务，并在多次调用间保留解析状态。连接 RPC 服务器，列出带 opnum 映射的方法，用存储的返回对象调用方法，并断开会话。在实验虚拟机中通过常驻客户机运行空间执行 PowerShell。套用固定的 CVE 挖掘流程：上下文句柄扫描、攻击面清点、默认试运行的模糊测试、可劫持接口发现、ETW 检查、ALPC 安全审计和标志位解码。导出生成的 C# 客户端源码、构建 NDR 结构体、抢占 ALPC 端口并列出用户可启动的任务。管理会话变量和解析缓存，每次调用都写入审计日志。
适用场景
适用于在隔离的实验虚拟机上开展经授权的 Windows RPC 安全研究和 CVE 方法论工作，让助手在步骤之间保留实时 RPC 会话和已解析对象，而不必反复执行一次性 PowerShell。不适用于生产或日常使用的主机。
运行要求
在 Windows PowerShell 5.1 上以本地 Python stdio 进程运行（pwsh 7 未测试）。需要安装 NtObjectManager PowerShell 模块和 Python 的 mcp 包。部分工具（ETW 跟踪、ALPC 安全描述符）需要管理员权限；虚拟机工具需要预先配置好的实验虚拟机。
安装前请注意
工具会调用真实的 RPC 方法，可能导致服务崩溃，只能在隔离虚拟机中使用。多个工具会写入或改变系统状态：ALPC 端口抢占、虚拟机监听器部署、模糊测试（默认试运行）和方法调用。ETW 与 ALPC 审计需要管理员权限。每次调用都会写入审计日志。发现的漏洞需遵循负责任披露。

安装

在 SourceWeft 中

  1. 打开 控制台中的 Ntobjmanager Mcp，将其添加到工作区。
  2. 为需要使用其工具的对话启用该服务。

Desktop only，通过 STDIO。 STDIO 服务会启动本地进程，因此需要 SourceWeft 桌面宿主。

其他 MCP 客户端

参照 仓库 中的启动说明。

README

🛰️ NtObjectManager-MCP

Stateful Windows RPC Research MCP — 2024–2026 CVE methodologies as one-click tools

[Python] [License] [PowerShell] [MCP]

🌐 中文版

What is NtObjectManager-MCP?

A Model Context Protocol server that gives an AI agent live, stateful access to Windows RPC attack-surface research, built on James Forshaw's NtObjectManager (NtCoreLib).

Three things a generic PowerShell MCP cannot do — and the reason this exists:

  1. Stateful RPC connections — a persistent PowerShell engine keeps parsed RpcServer objects and connected RPC clients alive across tool calls: rpc_connect once, rpc_call many times (auth handshakes, context-handle chains, session variables survive).
  2. CVE methodology as fixed tools — the standard hunting workflows from 2024–2026 public research are one-click, not prompt-engineering.
  3. Stateful execution inside a lab VM — the same one-engine principle applied in the guest: rpc_vm_exec keeps variables and connected RPC clients alive across calls through a single persistent guest runspace, never a fresh shell per call (the vmrun fallback is reported as 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) │└────────────────────────────────────────────────────────────────────┘

Tool Matrix (24)

Core stateful pipeline

ToolPurpose
rpc_parse(file, symbol_path?)Parse a PE for RPC servers, cache (keys file_N)
rpc_state()Cached servers + live sessions
rpc_get_interface(key)Procedures, NDR params, context handles, strictness
rpc_query_endpoints(ifid?, search_binding?, find_alpc_port?)EPM query (local or remote)
rpc_running_servers(pid?/service?)Live process/service enumeration
rpc_connect(session, key, binding?, auth?)Generate + connect client (stateful)
rpc_methods(session)Signatures with opnum mapping
rpc_call(session, method, args_json, store_as?)Reflection invoke; {"__var__"} passes stored objects
rpc_disconnect(session)Drop session

VM lab bridge (stateful guest execution)

ToolPurpose
rpc_vm_exec(ps, timeout?, vm?)Run PowerShell inside a lab VM; state survives across calls (persistent guest runspace)
rpc_vm_start_listener(vm?)Deploy/start the persistent guest HTTP engine (vm_listener.ps1)

2024–2026 CVE methodology tools

ToolMethodology source
rpc_scan_context_handles(paths)Context-handle type confusion — CVE-2025-48815 pattern (whereisk0shl 2026)
rpc_inventory(paths?, limit?)Attack-surface inventory + EPM cross-check — MS-RPC-Fuzzer phase 1 (CVE-2025-26651)
rpc_fuzz(session, dry_run=True)Primitive-only default-value fuzzing with ok/denied/error classification — dry-run by default
rpc_find_hijackable()Unregistered interfaces of stopped services — EPM poisoning / RPC-Racer (CVE-2025-49760/59200/59230)
rpc_etw_unreachable(duration, trigger_script?)Clients calling dead servers — PhantomRPC (Kaspersky 2026), admin required
rpc_interface_security(key)ALPC SD / anonymous-ACE audit — MS-NRPC null session (SafeBreach/Securelist 2025)
rpc_decode_flags(flags)RpcServerRegisterIf3 flag bitmask decoding
rpc_format_client(key)Export generated C# client source (offline grep workflow)
rpc_new_struct(session, type, store_as)Build NDR complex types as session vars
rpc_alpc_squat(name, duration)ALPC port squat + connection capture (race validation primitive)
rpc_accessible_tasks()User-startable tasks (Dark-Elevator chain material, CVE-2026-66804 pattern)
rpc_vars / rpc_clear_cacheSession-variable and cache management (eviction cap 150)

Every tool call is appended to output/mcp_audit.log.

Field-Tested (real machine, full hunting round)

CandidateResult
srvsvc.dll 98716d03… flagged HIGHIdentified as XactSrv (XsOpenPrinter/XsClosePrinter/XsAddJob/XsScheduleJob) — single printer-handle type; live probe: non-admin connect OK but XsOpenPrinter → ACCESS_DENIED (authorization gate works). Scanner false-positive mode documented
ssdpsrv.dll (CVE-2025-48815 original)All 20 context handles strict — patched state on current builds
51-module sweep31 findings, 6 HIGH, all "one producer → many consumers"; NDR layer cannot prove multi-type handles (needs RE)
EPM hijack surface10 stopped services with unregistered interfaces (AppIDSvc, ClipSVC, dcsvc…)
Task chains44 user-startable SYSTEM tasks inventoried
VerdictNo confirmable exploitable vuln on the tested host — with per-step evidence

🚀 Quick Start

powershell
# 1) Prerequisites (one-time)Install-Module NtObjectManager -Scope CurrentUser -Forcepip install -r requirements.txt            # mcp>=1.2.0 (1.x / 2.x compatible)
# 2) Verify — three suites, all greenpython 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 serverpython server.py                           # stdio MCP

Claude Code:

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

Any MCP client (e.g. OpenCode opencode.json):

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

Example: context-handle type confusion (CVE-2025-48815 pattern)

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) pairs4. rpc_connect s1 target_0                    → auto-discovers binding via EPM5. rpc_methods s1                            → opnum-mapped signatures6. rpc_call s1 XsOpenPrinter-like args store_as="h"   → keep the raw handle object7. rpc_call s1 XsClosePrinter-like [{"__var__":"h"}] → feed it to the other type

store_as / {"__var__"} is the core chain primitive: RPC return objects flow between calls without serialization round-trips, which is exactly what producer→consumer handle-confusion testing needs.

📁 Project Structure

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

🛡️ Honest Capability Boundaries

ClaimStatus
Stateful clients across tool callsYes — persistent engine + $RPCMCP
Stateful execution inside a lab VMYes — one persistent guest runspace (rpc_vm_exec); the vmrun fallback is stateless
Context-handle chaining (producer → consumer)Yes — store_as / __var__ raw-object passing
Auto-confirm type confusionNo — NDR cannot prove distinct handle types; verify via RE (see XactSrv case)
Full rogue-RPC hostingNo — NtObjectManager 2.0.1 ships no server builder; rpc_alpc_squat covers race-capture only
ETW tracing / ALPC SDDLRequires admin (logman / SeDebugPrivilege)
Symbol-resolved procedure namesEnvironment-dependent (symsrv chain); heuristic fallback names otherwise
Runs anywhere but Windows PS 5.1Not yet (pwsh 7 untested)

📖 Documentation

  • ARCHITECTURE.md — engine protocol, state model, design decisions
  • CHANGELOG.md — R1–R13 decision history incl. two PS 5.1 marshaling bugs
  • SECURITY.md — authorized use, VM isolation, MSRC disclosure
  • CONTRIBUTING.md — development invariants and test requirements

⚠️ Disclaimer

For lawful security research, education, and authorized testing only. rpc_call invokes real RPC methods and can crash services — run it against an isolated VM, never a production or daily-driver host. Vulnerabilities found through this tool must follow responsible disclosure (MSRC).

📄 License

MIT — Copyright (c) 2026 ntobjmanager-mcp Contributors

来源：README.md，提交 0c3f0f6

工具

0
SourceWeft 尚未在沙箱中启动过该软件包，因此其工具未知。

版本历史

1
  1. v1.0.0最新Sep 30, 2026

评分

已满足适用检查项的 50%

该评分衡量此收录条目的完整程度，依据注册中心条目、端点与公开来源计算得出。它不是对服务器本身的评价，也不表示服务器安全或当前可用：可连通性是带日期的检查结果，评分也不包含安装量或用户评价。

  • 近 30 天内可连通25 分

    请保持端点能够响应 MCP 握手；SourceWeft 每 30 天探测一次。

  • 已声明认证方式10 分

    请在注册中心条目中声明凭据请求头，或保持端点能够响应探测，以便判定其认证方式。

  • 已列出工具15 分

    请让服务器在无凭据时响应 tools/list，或发布可在沙箱中无凭据启动的软件包。

  • 描述必需15 分
  • 图标10 分
  • 文档15 分
  • 许可证10 分