键盘、鼠标这类 HID 设备被系统默认信任，驱动加载路径又依赖内核；当这两点相遇，管理员密码就不再是攻击链设计者必须拿下的目标。本文会从 Windows 权限模型、USB 设备信任链、攻击链环节拆解、防御检测和可落地的 PowerShell 审计脚本几个维度展开，尽量把这类攻击讲清楚，也讲明白防御侧可以做什么。
1. 这篇文章真正要解决的问题
很多 Windows 用户在修改某些系统文件时都会遇到一个经典报错：你需要来自 SYSTEM 的权限才能对此文件夹进行更改。这个报错现象，恰好说明了 Windows 权限体系里一个被大多数人忽略的事实——管理员并不是系统内的最高权限，真正掌控整个系统的是 SYSTEM 账户。如果攻击者能拿到 SYSTEM 权限，那么账号密码、UAC、文件权限这些在用户态设置的管理措施，基本都会被绕过。
这篇文章要讨论的核心问题是：为什么伪造 USB 设备可以被当成一条进入 SYSTEM 权限的路径？攻击链的设计者需要解决哪些前置条件？USB 设备与 Windows 驱动栈之间的信任关系是如何被利用的？作为防御者，我们又能在不影响业务的前提下，用哪些手段识别和缓解这类风险。
以下几个角色应该重点关注本文：负责企业 Windows 域环境的管理员、负责端点安全的安全工程师、做 Windows 客户端或硬件对接的研发人员，以及对红队攻击思路感兴趣的渗透测试初学者。需要特别强调的是，本文只做安全知识讲解和防御视角分析，不提供实际可用的攻击载荷，也不讨论具体的武器化利用细节。安全研究必须建立在合法授权和测试环境约束之下。
2. SYSTEM 权限模型：为什么攻击者把“内核级权限”当作目标
2.1 什么是 SYSTEM 权限
Windows 内部有一个本地系统账户，名为 LocalSystem，由操作系统自己创建和维护，它没有密码，也无法通过常规的交互登录直接使用。这个账户的安全标识符是 S-1-5-18，它的权限范围覆盖了几乎整个操作系统，包括修改系统文件、加载驱动、读取其他进程内存、操作注册表和活动目录数据库等。
要理解这个权限的层级，可以和普通管理员做对比。管理员账户虽然是电脑的“日常最高管理者”，但它仍然受到用户态组策略、UAC 和应用白名单的约束。SYSTEM 账户则运行在系统级上下文，不受普通用户态安全策略的完全约束。很多内核驱动、系统服务和安全软件本身也以 SYSTEM 权限运行，这进一步扩大了它的权限覆盖面。
2.2 管理员与 SYSTEM 的边界在哪
从权限模型来看，管理员和 SYSTEM 的差别可以这样理解：管理员被 Windows 的登录和审计机制管理着，SYSTEM 则是 Windows 自己的一部分。管理员登录后有明确的安全上下文，UAC 可以对这个上下文进行限制；而 SYSTEM 账户在系统启动早期就已经获得全套权限，许多内核子系统直接信任它。
从攻击视角看，如果目标只是管理员账户，攻击者需要破解口令、拿到访问令牌，或通过某个用户态的提权漏洞。但如果目标是 SYSTEM，攻击者通常要把代码放进内核态相关路径，或者在某个以 SYSTEM 权限运行的服务中执行代码。前者依赖认证体系，后者依赖系统组件的信任缺陷。这也是为什么“不需要管理员密码”并没有想象中那么不可思议：认证体系管的是用户态登录，SYSTEM 权限获取路径反而常出现在设备与内核子系统中。
2.3 为什么“不需要管理员密码”是攻击链的关键设计
在真实攻击场景中，获取管理员密码的难度远高于触发一次驱动加载或利用一个设备协议缺陷。攻击者设计攻击链时，会把认证成本、设备获取成本和系统组件信任成本放在一起比较。USB 攻击的价值在于，它把攻击入口从“必须知道密码才能进入的远程门槛”，转移到了“物理接触设备即可触发”的低门槛，同时绕过了最容易被用户感知的登录认证环节。
这里需要明确一点：绕过管理员密码不等于绕过所有安全机制。它绕过的只是用户态的认证边界，真正被利用的是 Windows 对即插即用设备的自动信任、驱动签名策略的局限性，以及内核组件对设备输入的处理路径。三者叠加，才可能形成从 USB 设备到 SYSTEM 权限的完整链条。
3. USB 信任模型：操作系统为什么会相信“伪造设备”
3.1 USB 设备类别与 HID 伪装原理
USB 设备插入后，并不会被立即当作存储设备处理。系统会先读取设备的描述符，再根据设备类别选择对应的驱动栈。常见类别包括大容量存储、通信设备、人机交互设备等。其中 HID 类别专门用于键盘、鼠标、触摸板这类输入设备，系统对它的处理方式是“直接信任输入”。
这里存在一个容易忽略的点：许多微控制器和开发板可以被配置成模拟 HID 键盘，系统并不会区分这个“键盘”是真实硬件还是控制器伪造的信号。这种能力在自动化测试、辅助输入设备等领域有合法用途，但也可以被改造为恶意输入设备。需要注意，仅模拟键盘本身并不会直接拿到 SYSTEM 权限，它更多是攻击链中的一环，本质上让攻击者可以代替用户向系统输入命令。
3.2 操作系统对 USB 设备的信任链条
当一个 USB 设备插入 Windows 时，系统会经历一整套流程：设备枚举、获取描述符、匹配设备类别和驱动、加载驱动、创建设备接口。这个流程的关键在于，Windows 默认信任 USB 设备提供的信息。设备描述符中的厂商 ID、产品 ID、序列号，都会被当成驱动选择和策略匹配的依据。如果设备固件没有额外身份验证，系统层面就很难区分插进来的是正规产品还是伪造设备。
这套信任链条在便利性和安全性之间做了取舍。即插即用让用户免去手动安装驱动的麻烦，代价是设备自述的身份决定了系统对它的处理方式。一旦某个驱动对特定设备描述符的处理存在缺陷，攻击者就可能通过构造描述符触发驱动层代码执行。从防御角度看，这种机制本身没有对错之分，但在高安全环境中必须增加额外校验。
3.3 设备签名校验的局限
不少管理员认为，Windows 要求驱动必须有数字签名，就能挡住伪造设备。实际上，数字签名校验的对象是驱动文件本身，而不是插入的物理设备。如果攻击者使用的驱动是合法签名的，或者利用的是系统自带的通用驱动，签名校验并不构成实际阻碍。
更常见的风险在于，许多企业内网设备使用的 USB 转串口、USB 转以太网控制器，其驱动本身就是第三方厂商的通用驱动，在大量机器上都会被自动安装。很多开发者在安装 FT231X、FT232R 这类 USB UART 驱动时都遇到过系统权限提示或驱动签名弹窗，这些体验侧面说明 USB 设备与驱动之间的信任关系在实际环境中是复杂的，并不能靠签名一刀切管理。攻击者也可能复用这类被广泛信任的驱动栈，寻找可利用的逻辑，而不是从零写一个驱动。
4. 攻击链环节拆解：不用管理员密码的关键设计
4.1 完整攻击链通常包含哪些环节
从公开的 USB 类安全研究和红队实践来看，一条从物理接触推进到 SYSTEM 权限的链，通常需要打通以下环节：
- 物理接入：攻击者把伪造 USB 设备插入目标机器，或通过社工诱导用户插入。
- 设备枚举与驱动匹配：系统识别设备为某类受信任设备，并自动加载对应驱动。
- 载荷传输或输入注入：设备模拟键盘、网络或存储，将指令或载荷送入系统。
- 提权利用：利用某个以 SYSTEM 权限运行的服务或驱动路径执行代码。
- 持久化与清理：留下后门或清理入侵痕迹。
攻击者不一定要亲临现场，也可以借助社会工程手段让目标用户自己插入恶意设备。但从技术角度讲，核心的权限提升环节仍然需要系统组件的配合，单纯靠一个可写 U 盘，并不能直接跨越用户态权限边界。
4.2 为什么账号密码环节可以被跳过
在传统攻击中，口令和密码是系统安全的第一道门。但在 USB 设备路径中，载荷的进入并不依赖账号认证，而是依赖系统对物理设备的信任。攻击链真正要解决的关键问题，变成了找到一条从设备驱动回调或设备输入处理路径，通往高权限进程或内核功能的路。
Windows 在系统启动和驱动加载阶段会使用 SYSTEM 账户执行大量操作，这意味着任何能在驱动加载流程中被代码执行的组件，天然具备高权限上下文。攻击链设计者最想找的是这样一个组件，并让 USB 设备成为触发它的开关。这就能解释，为什么某些攻击链会绕过登录认证：因为目标本来就不在用户态认证体系中，而在设备与驱动的交互路径上。
4.3 攻击链的伸缩性与适配成本
与远程漏洞利用相比，USB 类攻击链的适配成本集中在驱动栈匹配和系统版本兼容上。不同 Windows 版本、不同安全软件、不同设备控制器，都会直接影响链条的可行性。标题中的“就能”是有条件的，并非任何 Windows 系统都能被同一套流程覆盖。
攻击者需要根据目标环境调试设备固件、驱动参数和触发逻辑。从防御角度理解这一点，意味着我们仍然可以通过系统加固和监控压缩攻击面。这个思路很重要：防御并不需要堵住所有漏洞，只需要提高攻击者的适配成本，让链条在某个环节断裂。
5. 攻击链成立的技术前提与环境匹配
5.1 前提条件清单
以下条件如果同时存在，USB 伪造设备攻击的风险会明显上升：
- 目标主机允许普通用户插入并自动识别 USB 设备，没有实施硬件设备管控策略。
- 系统没有对驱动安装和设备接口做额外白名单限制。
- 操作系统版本与攻击者使用的载荷能够匹配，存在可利用的设备驱动路径。
- 目标机器的物理接触控制较弱，或者员工会主动插入来历不明的设备。
- 端点安全软件没有对异常 HID 输入、驱动加载、进程创建做行为监控。
需要说明，这些条件并不是“攻击成功”的充要条件，而是从攻击面评估角度归纳的高危信号。实际攻击需要满足更多细节，本文不展开具体技术路线。
5.2 哪些系统与场景更容易受影响
从场景看，以下环境风险更高：没有实施 USB 设备管控的传统企业办公网、工控现场的 USB 维护口、公共电脑机房，以及网络隔离但允许物理接触的开发测试区域。这类环境的共同特点是，管理者更关注网络边界和账号安全，却容易忽视 USB 接口这个最直接的物理入口。
在 Windows 桌面系统上，用户级安全配置差异很大。启用 BitLocker 和禁止可移动存储写入，并不能完全阻止 HID 类输入攻击，因为键盘输入并不依赖存储设备权限。这一点经常被非安全岗的运维误解，认为“禁用 U 盘写入就安全了”，实际上设备类别不同，防护逻辑也不一样。
5.3 对研发与运维的启发
研发团队在开发硬件对接功能时，应避免直接信任 USB 设备的描述符信息。对设备的厂商 ID、产品 ID、序列号不能只做展示用途，而应结合业务场景设计校验逻辑。运维团队则应把 USB 设备管理纳入统一端点策略，而不是只在文档里写“禁止私接设备”。从攻击链视角看，每个缓解措施都会增加攻击者的适配成本，很多攻击链会因为某一个环节受阻而整体失效。
6. 防御侧实践：用 PowerShell 审计 USB 设备（完整示例）
除了制度和硬件管控，还可以通过 Windows 自带的 PowerShell 和 WMI 接口，搭建一套轻量级的 USB 设备审计方案。下面的示例适合先在测试机或虚拟机上验证，再决定是否推广到生产环境。
6.1 枚举当前系统已接入的 USB 设备
先写一个基础脚本，把当前机器的 USB 设备清单导出为 CSV 文件，方便安全团队定期核查。
# 文件路径：audit-usb-devices.ps1 $devices = Get-PnpDevice -PresentOnly | Where-Object { $_.InstanceId -like 'USB\*' -or $_.InstanceId -like 'USBSTOR\*' } | Select-Object Status, Class, FriendlyName, InstanceId $devices | Export-Csv -Path "$env:USERPROFILE\Desktop\usb-devices.csv" -NoTypeInformation -Encoding UTF8 Write-Host "共发现 $($devices.Count) 个 USB 相关设备" Write-Host "结果已导出到 usb-devices.csv"这段脚本的关键点：使用 Get-PnpDevice 查询即插即用设备，过滤掉不以 USB 开头的设备；导出 CSV 便于后续对比。脚本需要管理员权限才能读取完整信息，建议在管理员终端中运行。
6.2 监控新接入的 USB 设备事件
静态审计不够，还可以用 WMI 事件订阅，实时监控系统中新出现的 USB 设备，并记录到日志文件。
# 文件路径：monitor-usb-insert.ps1 $query = "SELECT * FROM __InstanceCreationEvent WITHIN 2 WHERE TargetInstance ISA 'Win32_PnPEntity'" $action = { $device = $event.TargetInstance $time = Get-Date -Format "yyyy-MM-dd HH:mm:ss" $line = "$time | $($device.Name) | $($device.DeviceID)" Add-Content -Path "C:\Logs\usb-monitor.log" -Value $line Write-Host $line } Register-WmiEvent -Query $query -Action $action -SourceIdentifier UsbMonitor Write-Host "USB 监控已启动，按 Ctrl+C 停止"这段脚本用于记录新引入的即插即用设备，包括设备名称和设备 ID。建议先把 Logs 目录创建好，并调整脚本中的日志路径。需要注意，WMI 事件订阅在系统重启后会失效，如果需要长期运行，应该把脚本包装成 Windows 计划任务。
6.3 查询系统安全日志中的外部设备事件
如果系统开启了相关审计策略，事件日志会记录外部设备的接入情况。可以查询安全日志中的 6416 事件（外部设备已识别），用于排查可疑设备。
# 文件路径：query-usb-eventlog.ps1 $startTime = (Get-Date).AddDays(-7) $events = Get-WinEvent -FilterHashtable @{ LogName = 'Security' Id = 6416 StartTime = $startTime } -ErrorAction SilentlyContinue if ($events) { $events | Select-Object TimeCreated, Id, Message | Format-List } else { Write-Host "最近 7 天内没有检测到外部设备识别事件，或未开启对应审计策略" }这个脚本依赖系统审计策略，需要预先通过组策略或 auditpol 开启“审核即插即用设备”功能。如果查询结果为空，不一定代表没有设备接入，也可能是策略未启用，需要先在内网测试机验证策略状态。
6.4 检查高危 HID 设备接入的快速命令
针对 HID 键盘类设备的接入，可以执行下面的命令，重点排查非厂商常见设备的接入记录：
Get-WinEvent -LogName 'Microsoft-Windows-Kernel-PnP/Configuration' -MaxEvents 50 | Where-Object { $_.Message -match 'HID|Keyboard' } | Select-Object TimeCreated, Id, Message | Format-ListHID 设备的枚举信息会出现在系统内核 PnP 配置日志中。如果发现大量不认识的 HID 设备在短时间内插入，应尽快联系安全团队跟进。这类日志本身不包含完整的设备身份信息，需要与设备清单进一步核对。
7. 运行结果与效果验证
在管理员 PowerShell 中执行第一个脚本：
.\audit-usb-devices.ps1预期输出类似：
共发现 8 个 USB 相关设备 结果已导出到 usb-devices.csv打开桌面的 usb-devices.csv，可以看到每个 USB 设备的 Status、Class、FriendlyName、InstanceId。这里要特别注意 Class 为 HIDClass 的设备，确认是否与实际接入的键盘、鼠标硬件对应。
第二个脚本运行后，插入一个普通 U 盘，PowerShell 窗口应实时打印设备名称和设备 ID，同时 usb-monitor.log 中追加对应记录。如果日志目录不存在，脚本会报错，需要先创建 C:\Logs 目录：
New-Item -ItemType Directory -Path C:\Logs -Force第三个脚本运行时如果提示找不到事件，先检查审计策略。执行 auditpol 列出当前策略：
auditpol /get /category:"系统"在“系统”类别中，确认“审核即插即用设备”是否已启用。如果未启用，需要以管理员身份开启：
auditpol /set /subcategory:"审核即插即用设备" /success:enable /failure:disable以上脚本的验证目标是：确认我们能否及时发现异常 USB 设备的接入。如果脚本在测试环境中能够正常记录设备，说明这套轻量审计方案在企业内网有落地可行性；如果脚本无法获取设备或事件，通常是权限或审计策略问题，需要先解决这两个前置条件。
8. 企业级防御策略与检测建议
8.1 设备管控优先于禁用存储
如果企业暂时无法部署第三方 USB 管控软件，可以通过组策略先限制存储设备。但需要明确，存储设备限制对 HID 键盘模拟类攻击效果有限。更有效的方式是只在需要 USB 接口的工位开放设备白名单，并把未识别设备的驱动安装行为统一拦截。需要特批才能使用 U 盘，从流程上压缩攻击者的接入窗口。
8.2 驱动签名与最小驱动原则
在 Windows 安全策略中开启“代码完整性”和“设备驱动签名校验”，能阻止绝大多数未签名驱动的加载。对内部使用的 USB 转串口等工具，尽量统一选用有签名、有版本管理的驱动包，并定期更新。避免员工自行从搜索引擎下载来路不明的 USB 驱动安装包，这类安装包经常夹带签名过期或修改过的驱动文件。
8.3 日志集中与设备指纹基线
将上面示例脚本采集的设备清单、新设备接入日志集中到 SIEM 平台，通过设备指纹建立企业设备基线。新设备一旦出现在基线的“未知设备”名单中，自动触发告警。这个方案不需要购买昂贵的端点管控产品，门槛比较低，适合中小型团队先行落地。
8.4 个人与家庭场景的防护
普通用户最容易做到的几件事是：只使用自己购买的 U 盘和充电设备；不随意插拔公共区域的 USB 口；开启 Windows 安全中心的勒索软件防护和 SmartScreen；系统盘开启 BitLocker，降低设备丢失后的数据泄露风险。面对 USB 攻击链，用户自身的安全意识是最便宜也最有效的一道防线。
9. 常见的理解误区与排查思路
为了方便读者对照排查，把几个常见误区整理成表格。
| 误区 | 实际风险 | 正确做法 |
|---|---|---|
| “只要禁用 U 盘存储就安全了” | HID 类设备不依赖存储权限，依然可以输入指令 | 通过设备管控禁止非白名单的 HID 设备接入 |
| “管理员密码足够强就安全了” | SYSTEM 权限路径绕过用户态认证，密码强度不影响设备信任链 | 收紧设备接入、驱动加载和内核组件的攻击面 |
| “安装了杀毒软件就能拦截” | 传统杀毒对驱动态载荷和 HID 输入检测有限 | 启用行为检测、EDR，关注驱动加载和设备接入行为 |
| “USB 口不用就不会被攻击” | 攻击者可通过诱导用户插入设备完成接入 | 落实物理访问控制，检查并封堵闲置 USB 口 |
| “驱动有数字签名就安全” | 签名证明的是驱动来源，不代表驱动行为安全，也不代表设备可信 | 对签名驱动同样做行为审计和版本管理 |
如果发现自己所在的团队缺少 USB 设备审计能力，第一步不是立刻买设备管控产品，而是先回答四个问题：当前哪些设备允许接入？是否有审计日志？日志是否集中存储？异常事件是否有人跟进。把这四个问题想清楚，再做技术选型会更有针对性。
10. 最佳实践与后续学习方向
10.1 对安全工程师的建议
安全团队做此类攻击面评估时，一定要遵守合法授权和最小化测试原则。在真实环境中验证攻击链，必须事先获得明确的书面授权，在隔离网络中使用专用测试机，并在测试结束后清理环境和日志。未经授权在他人设备上做渗透测试，本身就是越界行为；即使技术分析再完整，也不能跨过法律和伦理边界。
10.2 对运维与研发的建议
运维人员可以把 USB 设备审计脚本做成计划任务，每天自动导出设备清单，并在设备清单文件变化时发出提醒。研发人员在开发硬件交互产品时，应避免把设备描述符当成唯一信任依据，尽量增加动态校验、时序校验或服务端会话认证，防止伪造设备直接获得业务信任。
10.3 后续学习方向
如果想把这块知识吃透，建议按这个顺序继续深入：先看懂 Windows 设备驱动框架和常见设备栈结构，再学习内核事件日志与 ETW 的监控方式，然后研究端点检测产品对设备接入和驱动加载的检测逻辑，最后回到权限模型本身，理解 SYSTEM、TrustedInstaller、内核会话等概念之间的差异。
还可以持续关注 Windows 安全补丁公告和社区安全研究团队的公开分析。很多 USB 类攻击链会随着系统更新而失效，但新的变形方式也会不断出现。安全是持续的对抗过程，不存在一劳永逸的防御方案，理解攻击链的构造思路，比记住某个具体漏洞更有长期价值。
