去年秋天，服复我帮一家做企业IM的举漏客户做内网渗透测试。扫到一台10.0.8.23的洞修Windows Server 2016，445端口开着，服复但打补丁打得很勤，举漏EternalBlue没戏。洞修换了几个思路，服复最后用DCE/RPC服务枚举拿到了域控的举漏完整服务列表，包括几个不该暴露的洞修接口——其中一个是MS-EFSRPC，后来成了他们整个域沦陷的服复起点。这事让我重新审视DCE服务枚举这个老话题。举漏

DCE/RPC（分布式计算环境/远程过程调用）是洞修Windows域环境里绕不开的东西。它不像HTTP那样直观，服复但几乎所有的举漏域管理操作都走这个通道——从用户认证到组策略下发，从服务控制到任务计划。洞修问题在于，很多管理员根本不知道自己的域里跑着哪些RPC服务，更别提这些服务绑定了哪些接口。攻击者不需要找漏洞，光是枚举就能拿到足够的信息来规划下一步。

枚举本身不是漏洞。漏洞在于默认配置下，DCE/RPC的端点映射器（Endpoint Mapper，端口135）对任何人开放查询。你连上去，发个请求，它就把所有注册的接口UUID、版本号、绑定端口全吐出来。这就像走进一栋大楼，前台直接把每个房间的钥匙和用途都告诉你。我见过太多内网，135端口对内网所有机器开放，没有任何访问控制。

具体怎么枚举？用impacket的rpcdump.py最直接。一条命令：rpcdump.py @10.0.8.23，输出里能看到几十个接口。重点看几个东西：接口名字里带“MS-”前缀的（微软官方协议）、版本号偏低的（老版本往往有已知问题）、绑定在动态高端口上的（说明不是系统核心服务，可能是第三方软件）。有一次我扫到一个接口叫“MS-RPRN”，版本1.0，绑在49152端口。这个接口后来被用来做打印机漏洞利用，但当时我更感兴趣的是——它为什么开着？问客户，客户说“我们没装打印机服务”。再查，是某个备份软件偷偷注册的。

修复这件事，思路要分两层。第一层是减少暴露面：域内机器之间，135端口不应该对所有网段开放。用Windows防火墙或者网络微隔离，只允许必要的管理跳板机访问。第二层是接口层面的控制。Windows有个东西叫“RPC接口限制”，在组策略里可以配。路径是：计算机配置→管理模板→系统→远程过程调用→RPC端点映射器。你可以设置“限制未认证的RPC客户端”，或者直接指定允许的接口UUID白名单。这招比较狠，配下去之后，未授权的枚举请求直接返回拒绝。

但别指望一劳永逸。我见过配了白名单的域，管理员自己忘了把备份软件的接口加进去，结果备份任务全挂，半夜被叫起来改策略。所以配之前，先跑一遍完整的枚举，把业务需要的接口列清楚。用rpcdump.py的输出，结合netstat -ano看端口对应的进程，再对一下服务列表。这个过程很枯燥，但比事后擦屁股强。

还有一个容易被忽略的点：DCE/RPC枚举不只在135端口。有些服务通过HTTP上的RPC（RPC over HTTP）走593端口，或者直接在高端口上绑定。我习惯用Nmap的rpcinfo脚本扫一遍全端口：nmap -p- --script rpcinfo 10.0.8.0/24。慢，但能发现那些不走135的漏网之鱼。上个月扫一个客户，就在8080端口上发现了一个Tomcat应用注册的RPC接口，那个接口没有任何认证，直接能调系统命令。

最后说个观察。很多安全团队把精力放在打补丁和杀毒上，对DCE/RPC枚举这种“信息泄露”级别的风险不当回事。但攻击链往往就是从一条rpcdump输出开始的。你不需要漏洞，只需要知道目标域里跑着什么，就能找到最薄弱的那个接口。修复的成本不高——几条防火墙规则，一个组策略设置。但前提是，你得先知道自己的域里到底在枚举出什么。