微软在2024年5月补丁日修掉了一个RDP远程代码执行漏洞，程代编号CVE-2024-38077。码执攻击者不需要任何认证，行漏直接向目标机器的洞解3389端口发送特制数据包，就能在系统权限下执行任意代码。程代听起来像电影桥段，码执但这是行漏真实存在的——而且补丁发布前，互联网上暴露的洞解RDP端点超过700万个。

RDP本身的程代设计缺陷不是第一次出事了。2019年的码执BlueKeep（CVE-2019-0708）也是类似路径，当时闹得沸沸扬扬，行漏因为蠕虫化利用的洞解门槛极低。这次CVE-2024-38077的程代利用条件同样不苛刻：只要目标开启了RDP服务，且未安装5月补丁，码执攻击者就能远程触发。行漏区别在于，BlueKeep影响的是较老版本Windows，而这次波及Windows Server 2022、Windows 11等较新系统。

漏洞出在RDP的授权处理模块。具体来说，当服务端解析客户端发来的特定认证请求时，存在一个整数溢出，导致堆缓冲区被越界写入。攻击者可以精心构造数据包，覆盖相邻内存结构中的函数指针，最终劫持执行流。微软在通告中将利用复杂度标为“低”，意味着武器化并不需要太高深的技术积累。

我注意到一个细节：很多中小企业的运维习惯是“RDP直接映射到公网，改个高位端口就当安全措施”。改端口能躲过批量扫描，但针对性的漏洞利用根本不依赖端口号。攻击者先通过Shodan或FOFA定位开放3389的主机，再根据返回的RDP握手信息判断系统版本，最后发送对应exp。整个过程自动化，单台机器从探测到沦陷可能不到三秒。

解决路径其实不复杂，但执行层面容易走样。

第一件事是打补丁。微软已经发布了修复程序，通过Windows Update或WSUS推送即可。但问题在于，很多企业内网存在大量长期不重启的服务器，补丁下载了却没生效。我见过一台Windows Server 2016跑了四年没重启，补丁堆了上百个，这种机器就是活靶子。

如果暂时无法打补丁，必须关闭RDP的公网暴露。用VPN、零信任网关或者RD Gateway做前置代理，让3389只监听在内网接口。别用端口转发，那等于没关。另外，启用网络级别认证（NLA）能挡掉一部分未认证攻击，但CVE-2024-38077在NLA握手阶段就能触发，所以NLA不是万能药。

对于必须开放RDP的场景，开RDP的审计日志。Windows事件查看器里，Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational日志会记录连接来源IP和认证结果。配合Sysmon或EDR，能捕捉到异常的数据包特征。不过说实话，等日志告警出来，攻击者往往已经拿到系统权限了。日志更多是事后追溯用。

还有一个容易忽略的点：RDP的会话劫持。攻击者拿下RDP服务后，可以直接接管已登录用户的会话，看到屏幕上的所有内容。如果管理员用RDP登录域控，凭据可能被Mimikatz抓取。所以即便漏洞修了，RDP的凭据保护也得跟上——启用Credential Guard，限制域管账户的RDP登录权限。

微软这次补丁发布后，GitHub上很快出现了PoC代码。虽然多数是触发崩溃而非稳定利用，但给攻击者提供了调试起点。从补丁发布到野外利用，窗口期通常只有几天到两周。安全团队如果还在走变更审批流程，攻击者已经进来了。

我的判断是：RDP漏洞会反复出现，因为协议本身太复杂，历史包袱太重。与其每次追着补丁跑，不如把RDP从公网彻底拿掉。远程办公用VPN，运维管理用跳板机，RDP只在内网互通。这个架构调整比打补丁麻烦，但能一劳永逸地砍掉大部分RDP攻击面。

(责任编辑：热点)