进行rpc扫描扫描渗透测试

凌晨两点，进行目标内网的扫试一台Windows Server 2016突然弹出了135端口的banner。我盯着屏幕，描扫描渗手指在键盘上悬停了三秒——这不是透测常规的web漏洞点，这是进行RPC的领地。多数渗透测试报告里，扫试RPC扫描只是描扫描渗Nmap输出里的一行灰色小字，但真正打过内网的透测人知道，这里藏着域控的进行钥匙。

先别急着上Metasploit。扫试裸奔的描扫描渗RPC扫描容易触发EDR的敏感操作日志，尤其当目标运行着Symantec或CrowdStrike时，透测高频的进行epmapper查询会直接拉响警报。我习惯先用`nmap -sS -p 135 --script msrpc-enum`做慢速探测，扫试把速率压到300包/秒以下，描扫描渗像夜行贼一样摸清对方是否开了RPC动态端口映射。如果返回的UUID列表里有`12345778-1234-abcd-ef00-0123456789ab`（LSASS的策略句柄），这台机器基本就是域成员——接下来要做的不是爆破，而是精准枚举。

真正的技术点在于RPC的间接利用。去年打某制造业客户时，我扫到一台文件服务器开放了135和445，但SMB空会话被禁用。常规思路到此为止，可RPC的`IRemoteWinSpool`接口还开着——通过MS-RPRN协议调用`RpcOpenPrinter`，我硬是构造了一个指向攻击机SMB共享的打印机驱动路径，触发系统账户回连，抓到了NTLMv2哈希。整个攻击链里，RPC扫描只占最初5%的侦察工作，但它决定了后续所有动作的走向。没有那一次精准的端口确认，我可能还在对445端口做无意义的暴力破解。

扫描时得留意RPC的版本差异。Windows 10 1809之后的系统默认启用RPC over HTTPS（端口593），这让传统TCP扫描直接失效。上个月测试一个混合云环境，边缘防火墙只放行了443，我差点漏掉内部的一台ADFS服务器——后来改用`rpcdump.py`走SSL隧道，才发现对方的`IRpcSS`接口暴露了证书私钥的存储路径。所以别迷信单一扫描器，RPC的协议栈是活的，你得跟着微软的补丁更新改打法。

说到防御方的视角，我见过最蠢的检测规则是单纯监控135端口的连接次数。真正专业的蓝队会关注RPC调用中的`Opnum`字段——比如`Opnum 0`对应`RpcBind`，但`Opnum 15`（`LsaOpenPolicy`）的异常频率才是攻击信号。有次我在客户环境里连续枚举域用户的SID，触发了他们的Sysmon事件ID 1（进程创建）和事件ID 10（远程线程注入），但因为没有匹配到已知的漏洞利用特征，告警被降级为低危。这种时候技术反而不重要了——你得懂业务，知道哪些RPC调用在正常运维里不会出现。

最后说句实在话：RPC扫描不是独立的技术环节，它是整个内网渗透的侦察触角。别指望一次全端口扫描就拿到域管权限，但每一次RPC的响应都像指纹一样留下线索。我习惯把扫描结果按`UUID + Opnum + 返回错误码`三个维度归档，比如`DCERPC_FAULT_REMOTE_ERROR`（错误码0x1C）通常表示权限不足，但连续出现三次后可能意味着目标在故意诱导你——这时候该撤了，对面可能有蜜罐。

工具链方面，`impacket`的`rpcdump.py`和`rpcclient`是最趁手的组合，但记得改默认的User-Agent字符串，否则会被Wireshark的规则直接标记。至于那些吹嘘“全自动RPC渗透”的脚本，多半会在真实环境里卡死在Windows防火墙的高级规则上。手动扫吧，慢点，但每一步都踩在实处。