排查服务所依赖dll是否被篡改，需按序核查注册表服务路径、验证文件签名与哈希、监控运行时加载行为，并分析系统日志；顺序为先配置、再文件、后行为。
服务管理中排查服务所依赖的 dll 文件是否被篡改，核心在于验证文件完整性、比对签名状态、检查加载行为及系统日志。这不是单纯“找文件”，而是围绕 windows 服务运行机制展开的链路式核查。
查服务注册信息与实际DLL路径
每个 Windows 服务在注册表中都明确指定了其服务二进制路径（ImagePath），该路径可能直接指向一个 EXE，也可能指向一个 DLL（如 Win32 服务型 DLL，需配合 svchost.exe -k 启动）。第一步必须确认服务真实加载的是哪个文件：
- 用命令
sc qc查看服务配置，重点关注 BINARY_PATH_NAME 字段； - 若路径含
svchost.exe -k，需进一步查注册表HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost下对应组的 DLL 列表； - 用
tasklist /svc /fi "imagename eq svchost.exe"匹配 PID 和服务名，再用Process Explorer（微软官方工具）右键对应进程 → “Properties” → “Image” 标签页，确认实际加载的 DLL 文件全路径和时间戳。
验文件数字签名与哈希值
DLL 被篡改最直接的证据是签名失效或哈希不匹配：
- 右键 DLL 文件 → “属性” → “数字签名” 选项卡：检查是否有有效签名、签名者是否为 Microsoft 或可信厂商、签名时间是否合理；若显示“此数字签名无效”或“未签名”，高度可疑；
- 用 PowerShell 计算文件 SHA256 哈希：
Get-FileHash -Algorithm SHA256 ""，再与官方渠道（如微软符号服务器、原厂安装包解压结果）提供的哈希比对； - 对系统级 DLL（如
advapi32.dll、rpcrt4.dll），可对比同版本 Windows 官方 ISO 中对应文件的哈希（例如从install.wim提取）。
监控服务启动时的DLL加载行为
篡改常发生在运行时劫持（如 DLL 劫持、API Hook），静态检查可能漏掉：
- 使用
ProcMon（Process Monitor）过滤条件设为：Process Name is svchost.exe+Operation is Load Image+Path ends with .dll，观察服务启动瞬间加载了哪些 DLL，路径是否异常（如来自临时文件夹、用户目录、非系统路径）； - 重点留意是否存在同名但路径非法的 DLL（例如本该加载
C:\Windows\System32\foo.dll，却加载了C:\Temp\foo.dll）； - 结合
sigcheck -i（Sysinternals 工具）检查加载 DLL 的签名详情，识别无签名、自签名或过期证书的可疑模块。
查系统日志与安全审计线索
Windows 安全日志（Event ID 4688、4663）和 PowerShell 脚本块日志可暴露篡改痕迹：
- 打开“事件查看器” → “Windows 日志” → “安全”，筛选
Event ID 4688（进程创建），查找服务启动时 svchost 进程的完整命令行，确认是否被注入参数或启动了额外进程； - 筛选
Event ID 4663（对象访问），若提前启用了“审核对象访问”策略，可查到对关键 DLL 文件的写入操作（需注意默认不开启）； - 检查
Applications and Services Logs\Microsoft\Windows\PowerShell\Operational，看是否有可疑脚本修改注册表服务项或替换文件； - 运行
sfc /scannow和DISM /Online /Cleanup-Image /RestoreHealth，若报告系统 DLL 被修改且无法修复，说明底层已遭破坏。
不复杂但容易忽略：很多“被篡改”其实是服务配置被恶意修改（比如 ImagePath 指向了木马 DLL），而不是原 DLL 文件本身被覆盖。所以先查注册表和服务配置，再验文件，最后看运行时行为——顺序不能乱。
