授权内网测试中如何区分 PsExec 横向验证与正常运维，并补齐日志证据链？

发布于2小时前2小时

背景与提问在一次已授权的内网渗透测试中，测试人员通过受控运维账号验证了主机间的远程服务执行能力。目标机出现了 7045 服务安装事件，但安全团队没有找到完整的登录、进程和共享访问记录。问题是：怎样确认这是一次基于 SMB/服务控制管理器的远程执行，如何排除正常运维行为，并给出可复测的修复方案？本文只讨论已取得书面授权的测试环境。建议预先固定源地址、测试账号、目标清单和时间窗口，避免把真实入侵与演练流量混在一起。问题定位：先建立时间线，不要只盯 7045PsExec 类工具通常不是由单一事件证明的。较可靠的判断方式，是围绕同一源地址、账号和两分钟左右的时间窗，关联以下证据：日志来源关键事件观察重点Security4624、4672、4688、5140、5145网络登录、特权分配、进程创建、ADMIN$ 或 IPC$ 访问System7045、7036临时服务安装及状态变化Sysmon1、3、11、13进程、网络连接、文件落地和注册表修改防火墙或 EDRTCP 445、RPC 动态端口源主机与目标主机之间的连接方向典型链路是：源主机访问目标的 IPC$ 或 ADMIN$；目标收到 Logon Type 3 的网络登录；可执行文件被写入 Windows 目录或管理共享对应路径；随后通过服务控制管理器创建服务；服务进程由 services.exe 派生。不同实现的文件名、服务名会变化，因此不要把 PSEXESVC 当作唯一特征。技术分析：如何形成闭环证据4624 中重点看 LogonType=3、TargetUserName、IpAddress 和 LogonId。若使用本机账号，还要确认远程 UAC 令牌过滤是否生效。5145 中检查 ShareName、RelativeTargetName 和 AccessMask。仅出现 IPC$ 不足以认定远程执行，但它能说明 SMB 会话存在。7045 中提取 ServiceName、ImagePath、ServiceType 和 StartType。ImagePath 指向临时可执行文件、随机文件名或非标准目录时应提高优先级。4688 或 Sysmon 1 中确认 ParentImage 是否为 services.exe，并把 SubjectLogonId 与 4624 的 LogonId 关联。Windows 原生日志字段因系统版本和采集器而异。若只有 7045，没有 4624、5145 或 4688，通常是审计策略未开启、日志被覆盖，或采集链路漏收，并不意味着没有网络登录。操作步骤第一步，在目标主机确认审计策略和日志容量。以下命令需要管理员权限，建议先记录当前配置，再在变更单范围内调整：auditpol /get /category:*
wevtutil gl Security
wevtutil gl System

REM 开启进程创建、登录、文件共享及详细文件共享审计
auditpol /set /subcategory:\"Process Creation\" /success:enable /failure:enable
auditpol /set /subcategory:\"Logon\" /success:enable /failure:enable
auditpol /set /subcategory:\"File Share\" /success:enable /failure:enable
auditpol /set /subcategory:\"Detailed File Share\" /success:enable /failure:enable

REM 让 4688 记录命令行；域环境应通过 GPO 统一下发
reg add \"HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\Audit\" ^
/v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1 /f第二步，以测试时间窗导出原始日志，保留 EVTX，不要只截图。下面示例筛选最近 30 分钟的关键事件：$start = (Get-Date).AddMinutes(-30)
$ids = 4624,4672,4688,5140,5145
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=$ids; StartTime=$start} |
Select-Object TimeCreated, Id, MachineName, Message |
Export-Csv .\\security-window.csv -NoTypeInformation -Encoding UTF8

Get-WinEvent -FilterHashtable @{LogName='System'; Id=7045,7036; StartTime=$start} |
Select-Object TimeCreated, Id, MachineName, Message |
Export-Csv .\\service-window.csv -NoTypeInformation -Encoding UTF8

wevtutil epl Security .\\Security.evtx
wevtutil epl System .\\System.evtx第三步，检查服务配置及对应文件。不要直接执行未知二进制；先做元数据和哈希采集：sc.exe query type= service state= all
sc.exe qc <可疑服务名>
Get-CimInstance Win32_Service |
Where-Object {$_.PathName -match 'Windows|ProgramData|Temp'} |
Select-Object Name,State,StartMode,PathName

Get-Item 'C:\\path\\suspect.exe' | Select-Object FullName,Length,CreationTimeUtc,LastWriteTimeUtc
Get-FileHash 'C:\\path\\suspect.exe' -Algorithm SHA256
Get-AuthenticodeSignature 'C:\\path\\suspect.exe'第四步，在集中日志平台做关联。核心不是某个固定服务名，而是同一目标在短时间内依次出现网络登录、管理共享访问、服务安装和 services.exe 子进程。可按以下逻辑实现：目标主机相同
AND 时间差小于 120 秒
AND Security.EventID IN (4624, 5145, 4688)
AND System.EventID = 7045
AND 4624.LogonType = 3
AND (5145.ShareName CONTAINS \"ADMIN$\" OR 5145.ShareName CONTAINS \"IPC$\")
AND (4688.ParentProcessName ENDSWITH \"\\services.exe\")常见误判与排查软件分发平台、备份代理和资产管理系统也会远程创建服务。应核对服务文件签名、安装源地址、变更工单和固定运维账号。7045 的 ImagePath 可能包含参数或被引号包裹。解析时不要简单按空格截断，否则会取错文件路径。事件时间存在转发延迟。关联时使用事件产生时间，并检查终端时钟与域控 NTP 偏差。如果目标只保留 System 日志，应检查高级审核策略是否被基础审核策略覆盖，并确认 Windows Event Forwarding 订阅没有排除 4624、4688、5145。远程服务创建成功但进程未启动时，仍可能有 7045 而没有预期的子进程。此时结合 7000、7009、7011 等服务失败事件判断。权限边界与风险判断如果普通域用户能够完成远程服务创建，优先检查其是否通过嵌套组、GPO Restricted Groups、组策略首选项或本地管理员复用获得了目标主机管理员权限。远程服务管理本质上要求高权限；问题通常不在工具本身，而在账号被授予了超出职责范围的本地管理能力。建议分别验证三条边界：测试账号是否能访问 ADMIN$；是否能打开 Service Control Manager 的创建服务权限；是否能以高完整性启动服务。每一步都应记录成功或拒绝结果，避免仅凭“命令执行成功”下结论。修复与复测建议取消普通运维账号在服务器和终端上的泛化本地管理员权限，按主机分组使用独立的受管账号；本地管理员密码使用 Windows LAPS 管理。限制横向 SMB：通过主机防火墙只允许指定管理跳板机访问 TCP 445，并限制 RPC 管理流量来源。对远程服务管理建立允许清单。检测新服务路径位于可写目录、文件无可信签名、服务名随机或来源不在管理网段的组合行为。通过 GPO 统一开启进程创建命令行、登录、文件共享和详细文件共享审计；提高 Security 与 System 日志容量，并转发到集中平台。修复后使用原测试账号从原源地址复测。预期结果应是 ADMIN$ 或服务创建被拒绝，同时防火墙、4625 或 5145 失败审计能留下可查询记录。总结判断 PsExec 类横向行为不能依赖单个 7045，也不应依赖固定服务名。更稳妥的办法是把 4624 的网络登录、5145 的管理共享访问、7045 的服务安装和 4688 或 Sysmon 1 的进程关系串成时间线，再结合账号权限、来源地址和变更记录排除正常运维。修复重点是收缩本地管理员范围、限制管理协议来源并补齐集中审计；复测既要验证攻击路径被阻断，也要验证失败行为仍然可见。

54分钟前54分钟

这类场景不要用“有没有 PSEXESVC”作为结论，因为正常运维和授权横向验证产生的主机行为几乎相同，而且 PsExec 的 -r 参数可以改服务名。建议按“身份、来源、变更、执行、网络、清理”六段做时间线，最后再用工单信息判定性质。

目标机上优先固定以下证据：

Security 4624：通常是 Logon Type 3，记录登录账号、源 IP、Logon ID。
Security 4672：同一 Logon ID 是否获得管理员特权。
Security 5140/5145：是否访问 ADMIN$、IPC$，以及落地文件路径。
System 7045、Security 4697：服务创建时间、服务名、镜像路径和创建者。
Security 4688 或 Sysmon 1：服务进程及其子进程，例如 cmd.exe、powershell.exe、测试程序。
Sysmon 11/17/18：服务文件落地，以及 psexecsvc 类命名管道；管道名只能作辅助特征，不能单独定性。

先导出原始 EVTX，避免只保留筛选后的截图：

mkdir C:\IR 2>nul
wevtutil epl Security C:\IR\Security.evtx /ow:true
wevtutil epl System C:\IR\System.evtx /ow:true
wevtutil epl Microsoft-Windows-Sysmon/Operational C:\IR\Sysmon.evtx /ow:true
certutil -hashfile C:\IR\Security.evtx SHA256
certutil -hashfile C:\IR\System.evtx SHA256
certutil -hashfile C:\IR\Sysmon.evtx SHA256

快速拉取相关事件时，建议保留 RecordId 和原始 XML，方便用 Logon ID、进程 GUID、源地址做关联：

$ids = 4624,4672,4688,4697,5140,5145
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=$ids; StartTime=(Get-Date).AddHours(-4)} |
  Select-Object TimeCreated,Id,RecordId,MachineName,Message |
  Export-Csv C:\IR\security_timeline.csv -NoTypeInformation -Encoding UTF8

Get-WinEvent -FilterHashtable @{LogName='System'; Id=7045; StartTime=(Get-Date).AddHours(-4)} |
  Format-List TimeCreated,RecordId,Message > C:\IR\service_7045.txt

源端也必须取证。目标机只能证明“某账号从某 IP 经 SMB 创建服务并执行”，无法证明操作者使用的是哪一个 PsExec 二进制。源端应查进程创建中的 psexec.exe/psexec64.exe、完整命令行、父进程、操作者登录会话，以及同一时刻到目标机 TCP/445 的连接。若有 EDR，建议用“源进程 → 445 连接 → 目标端 4624 → 5145 → 7045/4697 → 4688”串成一条链。

区分授权测试与正常运维，关键不是工具特征，而是将事件字段与控制面信息核对：

源 IP 是否为批准的跳板机或测试机；账号是否为本次授权的专用账号。
时间是否落在变更窗口，目标资产是否在授权清单内。
服务镜像的 SHA-256、签名、版本是否与运维软件仓库中的 PsExec 一致。
命令行和子进程是否符合测试用例；若出现凭据导出、关闭日志、跨出目标清单，应单独升级处置。
工单中是否记录操作者、命令、目标、开始/结束时间和回滚结果。仅凭账号名称或服务名不能归因。

如果目前缺少 4688 命令行、4697 或共享访问审计，可在后续窗口前补齐：

auditpol /set /subcategory:"Process Creation" /success:enable /failure:enable
auditpol /set /subcategory:"Security System Extension" /success:enable /failure:enable
auditpol /set /subcategory:"File Share" /success:enable /failure:enable
auditpol /set /subcategory:"Detailed File Share" /success:enable /failure:enable
reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Audit" ^
 /v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1 /f

最后注意时间基准：记录各主机时区和 NTP 偏差，统一转换成 UTC 再排序。一个比较完整的证据链应能回答：谁在什么源主机上，以哪个账号访问了哪台目标机，写入了什么文件，创建了什么服务，实际启动了什么子进程，以及这些动作对应哪张授权单。缺少其中一环时，结论宜写成“行为与 PsExec 远程服务执行一致”，不要直接写成“恶意横向”或“正常运维”。