Virtual Serial Port Driver：一场静默的内核权限博弈
在某次PLC远程调试现场，工程师发现HMI软件突然无法连接Modbus从站——不是线缆松动，也不是串口被占用，而是COM7在设备管理器中“凭空消失”。排查三天后，真相令人后怕：一台未打补丁的Windows 10工作站上，某款免签名VSPD驱动被恶意DLL劫持，在DriverEntry()中悄悄将\\Device\\VSPD0的ACL设为D:P(A;;GA;;;WD)（Everyone全控），随后一个普通域用户进程通过CreateFile("\\\\.\\COM7", ...)拿到了设备句柄，再调用自定义IOCTL清空了整个FIFO缓冲区——这不是功能故障，而是一次教科书级的内核级串口劫持。
这并非孤例。Virtual Serial Port Driver（VSPD）这类看似“只是配个虚拟COM口”的小工具，实则是Windows内核中一条裸露的神经末梢：它不经过HAL抽象、直连I/O管理器、可注册任意IRP派遣函数、能绕过大多数用户态沙箱监控。它的便利性与危险性，从来就是一枚硬币的两面。
服务账户：别让驱动替你当“皇帝”
很多团队部署VSPD时，第一反应是右键服务 → “属性” → “登录”选项卡 → 勾选“此账户”，然后填入一个高权限域账号。这种操作看似稳妥，实则埋下巨大隐患。
Windows服务账户的本质，不是“谁来运行这个程序”，而是“谁来代表这个驱动向内核申领特权”。当SCM以LocalSystem启动VSPD服务时，DriverEntry()获得的执行上下文自带SeLoadDriverPrivilege、SeDebugPrivilege，甚至隐式持有SeTcbPrivilege——这意味着驱动代码中任意一处ZwOpenProcess()调用，都可能打开系统进程中任意线程句柄；一次疏忽的ProbeForRead()遗漏，就可能触发BSOD或内存越界读取。
真正的解法，是让驱动“只拿该拿的权”。
从Windows 8开始，系统支持专用服务SID（Service SID）。它不对应真实用户，而是一个仅存在于LSASS令牌中的抽象标识符，形如NT SERVICE\VSPD。这个SID天然不具备任何用户组成员资格，也不会继承LocalSystem的默认特权集。你必须显式授予它所需权限——这恰恰是安全设计的起点。
# 创建服务时强制使用专用SID（推荐方式） sc create VSPD binPath= "C:\Drivers\VSPD.sys" type= kernel start= auto sc sidtype VSPD u
