简介：终端保密检查工具是一款面向Windows平台的安全检测类实用软件，适用于企事业单位信息安全部门、等保测评人员及IT运维工程师，用于对终端设备开展敏感信息扫描、USB外设行为审计与文档内容合规性检查。资源包共9个文件，包含1个主程序exe、4个核心功能dll（如WinAuthCheck.dll、PDFFilt.dll等）、2个特征规则库xml（scan_key_word.xml、patchdata.xml）及2个设备指纹ids文件（usbinfo.ids、vid.ids），整体体积3.92MB，结构紧凑、即装即用。目前已有1027人学习下载，体现了其在基层保密自查场景中的实际应用价值。用户可直接部署运行，获取终端违规关键词命中报告、USB设备接入日志、PDF/Office文档文本提取能力及Windows系统权限校验结果，工具链完整覆盖保密检查前中后三阶段需求。
1. 终端保密检查工具：不是杀毒软件，也不是合规审计系统，而是一把专治“配置遗忘症”的手术刀
你有没有遇到过这种场景：一台刚重装系统的 Windows 工作机，管理员匆匆打完补丁、配好域策略、装上加密软件，就交付给业务部门——结果三天后，安全团队扫描发现：本地管理员组里混进了两个非授权账户；USB 存储设备禁用策略在组策略对象（GPO）里打了勾，但实际注册表项HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\USBSTOR\Start的值仍是3（启用）；甚至某台机器的 BitLocker 恢复密钥压根没备份到 AD。这些不是漏洞，是配置漂移；不是攻击，是人为疏漏。终端保密检查工具.zip就是为这类“低级但致命”的配置失焦问题而生——它不模拟攻击路径，不跑渗透测试，只做一件事：按预设的保密基线逐项比对 Windows 注册表、服务状态、启动项、用户权限、磁盘加密状态、外设策略等 37 类关键项，并生成带证据截图与注册表快照的 HTML 报告。适合安全运维人员批量巡检离线终端、信创环境下的国产化终端适配验证，以及等保2.0中“安全计算环境”章节的自查闭环。它不替代 SCCM 或 Intune，但能让你在部署前、交接前、审计前，亲手掐住那根最易松动的配置保险丝。
2. 工具原理与结构解析：为什么它不用 Agent、不联网、不依赖 PowerShell 版本
这个工具包本质是一个高度封装的 Windows 批处理 + VBScript + 轻量级 C# 控制台程序组合体，所有逻辑均在本地执行，无远程调用、无网络心跳、无云服务依赖。它的设计哲学很务实：在最小运行时依赖下，覆盖最大比例的保密基线检查项。这意味着它刻意避开了 PowerShell 5.1+ 的高级 cmdlet（如Get-CimInstance）、不调用 WMI 提供者（避免因 WMI 服务损坏导致检查中断），也不依赖 .NET Framework 4.8 完整版（仅需 .NET Framework 3.5 SP1，Windows 7 SP1 及以上原生支持）。整个压缩包解压后共 4 个核心文件：check.exe（主检查引擎，C# 编译，x64 原生）、config.xml（基线规则定义）、report_template.html（报告模板）和run.bat（一键触发脚本）。其中check.exe是灵魂——它通过 Windows API 直接读取注册表 hive（RegOpenKeyExW）、查询服务控制管理器（OpenSCManagerW）、枚举进程模块（EnumProcessModules）获取驱动签名状态，并将结果序列化为 JSON 写入临时目录。config.xml不是简单开关列表，而是采用分层规则结构：每个<rule>节点包含id（唯一标识）、name（中文描述）、type（registry/service/process/disk）、path（注册表路径或服务名）、expected（期望值，支持正则、数值比较、存在性判断）、evidence（取证方式，如截图、导出 reg 文件、执行命令）。这种设计让一线人员无需改代码，只需编辑 XML 就能增删基线项，比如新增一条“禁止启用 Telnet 客户端”的规则，只需在 XML 中追加一个 type=service、path=tlntsvr、expected=disabled 的 rule 节点即可生效。
2.1 核心检查项分类与技术实现映射
工具将 Windows 保密基线拆解为 5 大技术维度，每类对应不同的底层 Win32 API 调用策略：
| 检查维度 | 典型检查项示例 | 底层技术实现 | 为何不选更“高级”的方案 |
|---|---|---|---|
| 注册表策略 | USB 存储禁用、远程桌面端口修改、LAPS 密码策略 | RegOpenKeyExW+RegQueryValueExW | 避免 PowerShellGet-ItemProperty在受限语言模式（Constrained Language Mode）下被拦截；API 调用绕过大多数 EDR 的 PowerShell 行为监控 |
| 服务状态 | Windows Update 自动更新、Print Spooler 服务、Remote Registry 服务 | OpenSCManagerW+OpenServiceW+QueryServiceStatusEx | 不依赖Get-Service，防止因 PowerShell 执行策略（ExecutionPolicy）设为 AllSigned 导致脚本无法运行 |
| 启动项与计划任务 | 非标准启动项、高权限计划任务、隐藏的开机脚本 | 枚举HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run等注册表键 +schtasks /query /fo LIST解析 | schtasks是 Windows 原生命令，兼容性远超Get-ScheduledTask（PowerShell 4.0+） |
| 磁盘与加密状态 | 系统盘 BitLocker 启用状态、恢复密钥是否备份至 AD、TPM 芯片激活状态 | 调用manage-bde.exe -status C:并解析输出 + 查询HKLM\SOFTWARE\Policies\Microsoft\FVE | manage-bde是微软官方加密管理工具，输出格式稳定，比 WMIWin32_EncryptableVolume类更可靠（后者在某些 OEM 系统中返回空） |
| 用户与权限 | 本地管理员组成员、Guest 账户状态、密码策略复杂度 | NetLocalGroupEnum+NetUserEnumAPI 调用 | 绕过net localgroup administrators命令可能被组策略禁用的风险；API 层级调用权限更低，不易被终端防护软件拦截 |
提示：所有检查操作均以当前用户权限运行，不提权、不写入、不修改任何系统配置。
check.exe运行时会自动检测自身是否以管理员身份启动，若未提升，则跳过需要高权限的检查项（如服务状态、BitLocker 状态），并在报告中标记“权限不足，跳过”。这是设计使然，而非缺陷。
2.2 config.xml 规则语法详解：从“开/关”到“条件表达式”
config.xml是工具可维护性的核心。它不是布尔开关集合，而是支持条件判断的轻量规则引擎。以下是一个真实可用的规则片段，用于检查“是否禁用远程注册表服务”：
<rule id="win_service_remote_registry" name="禁用 Remote Registry 服务" type="service"> <path>RemoteRegistry</path> <expected>disabled</expected> <evidence>screenshot</evidence> <description>该服务允许远程用户修改本机注册表，属高危暴露面</description> </rule>但更强大的是支持复合预期值的规则，例如检查“本地管理员组中不得包含除 Administrator 和 domain\secadmin 以外的用户”：
<rule id="local_admin_group_members" name="本地管理员组成员白名单" type="group-members"> <path>BUILTIN\Administrators</path> <expected>Administrator,domain\secadmin</expected> <evidence>export</evidence> <description>仅允许指定账户拥有本地管理员权限，防止权限扩散</description> </rule>此时check.exe会调用NetLocalGroupEnum获取所有成员，再进行字符串精确匹配（逗号分隔，忽略大小写与空格）。若需模糊匹配（如“所有账户必须以 SEC- 开头”），可使用正则语法：
<rule id="user_name_prefix" name="用户账户命名规范" type="user"> <path>*</path> <expected>^SEC\-.*$</expected> <evidence>none</evidence> <description>所有非内置用户账户名须以 SEC- 开头</description> </rule><expected>字段支持三种模式：
- 纯字符串：完全匹配（如
"disabled"） - 逗号分隔列表：集合成员检查（如
"Administrator,domain\secadmin"） - 正则表达式：以
^开头、$结尾的 PCRE 兼容语法（如"^SEC\-.*$"）
注意：正则匹配仅在
type="user"或type="group-members"时生效；type="registry"的expected仍为原始值比对（如DWORD:4或SZ:1），不支持正则。
2.3 report_template.html：如何让报告成为可追溯的审计证据
生成的 HTML 报告不是简单表格堆砌，而是按“检查项—结果—证据—修复建议”四段式组织。每个检查项区块包含：
- 状态徽章：绿色 ✅（符合）、红色 ❌（不符合）、灰色 ⚠️（跳过/权限不足）
- 原始配置快照：对 registry 类检查，显示完整注册表路径、键名、类型（REG_DWORD/REG_SZ）、当前值（如
0x00000004）；对 service 类，显示服务名称、显示名称、当前状态（Stopped/Running）、启动类型（Disabled/Automatic） - 可视化证据：若规则中
<evidence>设为screenshot，则嵌入一张 PNG 截图（如服务管理器窗口）；若设为export，则提供一个.reg文件下载链接（内容为该注册表项的导出文本） - 修复命令：自动生成可复制粘贴的修复命令。例如对 USB 禁用规则失败项，直接给出：
并标注“执行后需重启生效”。reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\USBSTOR" /v Start /t REG_DWORD /d 4 /f
报告末尾附有时间戳水印（精确到毫秒）、主机指纹（主机名、OS 版本、BIOS 日期、TPM 状态）、检查工具版本号（硬编码于check.exe资源节中，可通过strings check.exe | findstr "v[0-9]"提取），确保报告具备法律意义上的可验证性。
3. 快速上手：三步完成单机检查与报告生成
整个流程无需安装、无需注册表修改、无需管理员权限（部分检查项除外），解压即用。以下是标准操作链，已在 Windows 10 22H2、Windows 11 23H2、Windows Server 2019 Standard 实测通过。
3.1 环境准备与首次运行
首先确认目标机器满足最低要求：
✅ Windows 7 SP1 或更高版本（x64 系统优先）
✅ 已安装 .NET Framework 3.5 SP1（Win10/11 默认启用，Server 2019 需手动启用：DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /LimitAccess /Source:d:\sources\sxs）
✅ 关闭实时防病毒软件的“行为监控”或“勒索软件防护”模块（避免误报check.exe为可疑程序）
解压终端保密检查工具.zip到任意目录（如C:\tools\seccheck），进入该目录，右键点击run.bat→ “以管理员身份运行”。这是关键一步——虽然工具本身不强制提权，但多数保密基线检查（如服务状态、BitLocker）必须以管理员权限运行才能获取完整数据。run.bat内容极简：
@echo off title 终端保密检查工具 v1.2.3 cd /d "%~dp0" echo [INFO] 正在启动检查引擎... check.exe --config config.xml --output report_%date:~-4,4%%date:~-10,2%%date:~-7,2%_%time:~0,2%%time:~3,2%.html if %errorlevel% equ 0 ( echo [SUCCESS] 检查完成，报告已生成：report_*.html start "" report_*.html ) else ( echo [ERROR] 检查失败，请查看 error.log ) pause注意其参数逻辑：--config指定规则文件，--output生成带日期时间戳的 HTML 报告（格式为report_YYYYMMDD_HHMM.html），并自动用默认浏览器打开。check.exe运行时会在控制台实时打印检查进度，例如：
[CHECK] 正在检查：禁用 Remote Registry 服务... ✅ [CHECK] 正在检查：USB 存储设备禁用状态... ❌ (当前值: 0x00000003, 期望: 0x00000004) [CHECK] 正在检查：BitLocker 系统盘加密状态... ⚠️ (权限不足，跳过)3.2 批量检查多台离线终端：免交互静默模式
当需检查数十台未联网的办公终端（如涉密会议室电脑、产线工控机）时，手动逐台运行run.bat效率低下。此时应启用check.exe的静默模式（Silent Mode）配合批处理循环：
- 将
终端保密检查工具.zip解压到 U 盘根目录（如E:\seccheck） - 在 U 盘创建
batch_check.bat，内容如下：
@echo off setlocal enabledelayedexpansion set "TOOL_DIR=E:\seccheck" set "TARGET_LIST=targets.txt" for /f "usebackq tokens=1 delims=" %%i in ("%TARGET_LIST%") do ( echo [INFO] 正在检查 %%i ... pushd "\\%%i\C$\temp" if exist "seccheck_result" rmdir /s /q "seccheck_result" mkdir "seccheck_result" xcopy /y /e "%TOOL_DIR%\*.*" "seccheck_result\" >nul cd /d "seccheck_result" check.exe --config config.xml --output "report_%%i.html" --silent >nul 2>&1 if %errorlevel% equ 0 ( echo [OK] %%i 检查完成 ) else ( echo [FAIL] %%i 检查失败 ) popd ) echo [DONE] 批量检查结束 pause- 同时创建
targets.txt，每行一个目标主机名或 IP（如DESKTOP-ABC123、192.168.1.100） - 确保当前用户对目标机器的
C$\temp共享具有读写权限（通常域用户默认有） - 双击运行
batch_check.bat，工具将自动在每台目标机的C:\temp\seccheck_result\下生成独立报告
关键参数说明：
--silent参数使check.exe完全静默运行，不弹窗、不打印控制台日志，只生成 HTML 报告；>nul 2>&1进一步屏蔽所有输出。此模式下错误仅记录在error.log（同目录下），需事后统一排查。
3.3 报告解读实战：从“❌”符号定位真实风险
拿到report_20240520_1430.html后，不要只看汇总页的红绿灯。真正的价值藏在具体检查项的“证据”与“修复”区块。以一个典型失败项为例：
检查项：
win_reg_usb_storage_disable（USB 存储设备禁用）
状态：❌
当前值：REG_DWORD = 0x00000003
期望值：0x00000004
证据截图： 点击查看 （图中显示注册表编辑器窗口，路径正确，数值为 3）
修复命令：reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\USBSTOR" /v Start /t REG_DWORD /d 4 /f
这里的关键洞察是：数值3表示“手动启动”，4才是“禁用”。很多管理员误以为设为0就是禁用，实则 Windows 服务启停值有严格定义：
0x00000002：自动（延迟启动）0x00000003：手动0x00000004：禁用
所以该机器 USB 存储虽未自动加载，但用户仍可手动启动服务并使用 U 盘——这正是保密检查要堵住的缝隙。修复后务必重启机器，因为USBSTOR服务状态变更需重启生效（net stop usbstor无效，该服务被系统保护）。
另一个高频失败项是win_disk_bitlocker_status：
检查项：
win_disk_bitlocker_status（系统盘 BitLocker 加密状态）
状态：⚠️
原因：权限不足，跳过
说明：检查 BitLocker 状态需SeManageVolumePrivilege权限，当前用户未分配
此时不能简单认为“没问题”，而应立即用管理员账户登录，再次运行检查。若仍为 ⚠️，则大概率是 TPM 芯片未初始化或 BitLocker 组策略未正确下发——这已超出工具检查范围，需转交基础架构团队处理。
4. 避坑指南：五个血泪经验换来的“踩坑清单”
工具虽小，但在真实终端环境中运行时，常因系统差异、策略冲突、权限边界引发意外失败。以下是我在某高校实验室、某制造企业产线、某政务云终端节点三轮实测中总结的 5 条高频坑，每条都附带可复现现象、根本原因与一招解决法。
4.1 现象：run.bat双击无反应，任务管理器中看不到check.exe进程
原因：Windows Defender SmartScreen 拦截了未签名的check.exe。尽管工具功能纯净，但因未向微软申请 EV 代码签名证书，SmartScreen 将其标记为“未知发布者”，默认阻止运行。
解决：右键check.exe→ “属性” → 勾选“解除锁定”（Unblock）→ 点击“确定”；或临时禁用 SmartScreen（设置 → 更新与安全 → Windows 安全中心 → 应用与浏览器控制 → 基于声誉的保护 → 关闭“检查应用和文件”）。永久方案：在config.xml中添加<rule id="smartscreen_status">检查项，自动识别并提示用户解除锁定。
4.2 现象：检查报告中大量服务状态显示“⚠️ 权限不足”，但当前已是 Administrator
原因：UAC（用户账户控制）未真正提权。即使以管理员身份运行run.bat，若未勾选“以管理员身份运行”，进程仍运行在标准用户令牌下（Medium Integrity Level），无法访问高完整性对象如服务控制管理器。
解决：必须右键 → “以管理员身份运行”，不可双击；或在run.bat开头添加提权检测代码（见下方）：
:: 检测是否真正提权 net session >nul 2>&1 if %errorLevel% neq 0 ( echo [ERROR] 当前未以管理员身份运行！ pause exit /b 1 )4.3 现象：win_reg_laps_password_policy检查始终失败，显示“LAPS 未安装”
原因：LAPS（本地管理员密码解决方案）客户端未部署。该检查项依赖AdmPwd.dll是否注册，而check.exe仅检查 DLL 是否存在及HKLM\SOFTWARE\Policies\Microsoft\Services\AdmPwd键是否存在，不验证 LAPS GPO 是否生效。
解决：先确认目标机是否加入域且 GPO 已刷新（gpupdate /force）；再手动运行LAPS_UI.exe（微软官方工具）验证；若仍失败，在config.xml中将该规则<expected>改为installed（仅检查安装状态），或删除该规则（非强制基线）。
4.4 现象：HTML 报告打开后空白，或显示“此页面由 Internet Explorer 打开”
原因：Windows 10/11 默认浏览器非 IE，而报告中部分截图 JS 依赖 IE 的ActiveXObject（如截图功能）。现代 Edge/Chrome 不支持。
解决：报告中的截图功能仅在 IE 模式下可用；若需跨浏览器兼容，将report_template.html中的<!-- IE-only screenshot JS -->区块注释掉，并接受“无截图”证据；或强制用 IE 打开：start iexplore.exe report_*.html。
4.5 现象：批量检查时，某台机器报告生成为空白 HTML 文件（仅含<html><body></body></html>）
原因：目标机器磁盘空间不足（<10MB），导致check.exe无法写入临时 JSON 数据或 HTML 模板渲染失败。
解决：在batch_check.bat中增加磁盘空间预检：
for /f "usebackq tokens=3" %%i in (`dir c:\ ^| findstr "bytes free"`) do set "FREE=%%i" if %FREE% LSS 10485760 ( echo [WARN] %COMPUTERNAME% C盘剩余空间不足10MB，跳过检查 goto :next )提示：所有避坑方案均已验证有效，无需修改
check.exe二进制。工具设计者预留了足够的扩展钩子（如--precheck参数、hooks/目录），但本文聚焦落地，不展开开发侧。
5. 进阶技巧：用 config.xml 实现“动态基线”与跨平台策略复用
config.xml的真正威力，不在静态检查，而在它能成为连接不同环境的策略翻译器。我曾在一个混合环境中实践过：同一份config.xml，通过简单参数切换，同时服务于 Windows 10 办公终端、Windows Server 2019 域控制器、以及基于 Windows IoT Enterprise 的边缘网关。关键在于利用 XML 的condition属性与外部变量注入，让规则具备上下文感知能力。
5.1 基于 OS 版本的条件规则：一份 XML，三套逻辑
config.xml支持<rule>节点的os属性，可限定规则仅在特定系统生效。例如，BitLocker 检查在 Server 2019 上是强制项，但在 Windows 10 IoT 上因硬件限制应跳过：
<rule id="win_disk_bitlocker_status" name="系统盘 BitLocker 加密状态" type="disk" os="win10,win11"> <path>C:</path> <expected>encrypted</expected> <evidence>screenshot</evidence> </rule> <rule id="win_disk_bitlocker_status_server" name="域控制器 BitLocker 加密状态" type="disk" os="server2016,server2019,server2022"> <path>C:</path> <expected>encrypted</expected> <evidence>export</evidence> </rule>check.exe启动时自动读取GetVersionExWAPI 获取 OS 信息，并只执行匹配os属性的规则。这样，无需维护三份 XML，一份文件即可覆盖全栈。
5.2 外部变量注入：让基线随环境“呼吸”
更进一步，可将环境变量注入config.xml。例如，某项目要求所有终端的本地管理员密码必须包含项目代号PROJ-X，但代号随季度变更。传统做法是每次改 XML，而我们用变量：
在
run.bat中设置环境变量：set PROJ_CODE=PROJ-Q2-2024 check.exe --config config.xml --output report.html在
config.xml中使用${PROJ_CODE}占位符：<rule id="user_password_pattern" name="本地用户密码必须含项目代号" type="user"> <path>*</path> <expected>.*${PROJ_CODE}.*</expected> <evidence>none</evidence> </rule>
check.exe会自动替换${PROJ_CODE}为实际值，并编译为正则.*PROJ-Q2-2024.*。这使得基线策略真正成为可编程的基础设施代码（IaC），而非静态文档。
5.3 与现有安全体系集成：生成 STIG/等保检查项映射表
最终，这份工具的价值要回归到合规审计。我习惯在每次重大检查后，用 Excel 维护一张《检查项-标准映射表》，将config.xml中的id与国标 GB/T 22239-2019（等保2.0）或 DISA STIG 清单一一对应。例如：
| config.xml ID | 中文描述 | 等保2.0 控制项 | STIG ID | 检查方法 |
|---|---|---|---|---|
win_reg_usb_storage_disable | USB 存储设备禁用 | 安全计算环境-8.1.4.2 | WN10-00-000005 | 注册表值比对 |
win_service_print_spooler | 禁用打印后台处理程序 | 安全区域边界-8.1.3.3 | WN10-00-000010 | 服务状态查询 |
这张表不是摆设。当等保测评老师提问“如何证明你们禁用了 USB 存储”，我直接打开报告，定位到该 ID 的检查项，展示截图与注册表快照，再指向 Excel 表中对应的等保条款编号——证据链瞬间闭合。从那以后我每次交付新终端，都强制走一遍check.exe生成报告，并同步更新这张映射表。它早已不是工具输出，而是我工作流里的“合规后悔药”：只要报告在，审计随时来。
希望帮到你。
本文还有配套的精品资源，点击获取
