发布于周六 18:572天前 背景最近在一次授权渗透测试复盘里，客户安全团队提了一个比较典型的问题：堡垒机和 EDR 都提示某台应用服务器存在“疑似横向移动”，但现场没有明确的入侵证据。问答中心里这类问题经常出现，单看一条告警很难下结论，需要把身份、网络、进程、日志几条线串起来确认。场景如下：目标环境：Windows Server 2019，加入域，部署 IIS 和一个 Java 后台服务。授权范围：仅允许验证指定网段内主机的弱口令、配置错误、权限边界问题，不允许破坏性操作。告警现象：某应用服务器在夜间对多台内网主机的 445、135、5985 端口有连接记录。客户疑问：这是业务行为、运维行为，还是渗透测试过程中触发的横向移动迹象？问题定位思路这类问题建议不要先判断“有没有被控”，而是先回答三个问题：连接是谁发起的：哪个账号、哪个进程、哪个父进程。连接去了哪里：目标主机、端口、时间窗口是否符合业务逻辑。连接后做了什么：是否存在远程服务创建、计划任务、WMI、WinRM、SMB 文件写入等行为。如果只看到 445 端口连接，并不能直接等同于横向移动。Windows 域环境中，文件共享、组策略、杀软更新、备份系统都可能产生 SMB 流量。关键是把网络连接和主机行为对齐。技术分析在 Windows 内网里，常见的横向验证链路一般会留下这些痕迹：SMB：访问 ADMIN$、C$、IPC$，可能伴随 4624 登录事件，Logon Type 通常为 3。PsExec 类行为：目标机可能出现 7045 服务创建事件，服务名可能随机或可疑。WinRM：5985/5986 端口连接，目标机可能有 PowerShell Remoting 相关日志。WMI：DCOM/RPC 相关连接，可能在 WMI-Activity 日志中留下 5857、5858、5861 等事件。凭据使用异常：同一账号在短时间内登录多台服务器，且登录源不符合日常运维路径。本次排查中，客户提供的网络侧记录显示应用服务器 10.10.20.15 在 01:13 至 01:18 访问了 10.10.30.0/24 内多台主机的 445 和 135。这个时间点不是备份窗口，也不是补丁窗口，需要继续查主机日志。操作步骤建议按照以下顺序排查，避免一上来就扫全域日志，效率会高很多。第一步：确认应用服务器本机在告警时间段的活动账号。第二步：确认是否有可疑进程发起网络连接。第三步：在被访问主机上查登录事件和服务创建事件。第四步：对比堡垒机、运维平台、计划任务，排除正常运维。第五步：如果是授权测试行为，整理证据链并给出边界说明；如果不是，进入应急排查流程。命令示例下面这些命令适合在授权范围内做快速确认。注意尽量只读查询，不要修改目标主机配置。# 1. 在疑似源主机上查看近期网络连接进程 Get-NetTCPConnection | Where-Object { $_.RemotePort -in 445,135,5985,5986 } | Select-Object LocalAddress,LocalPort,RemoteAddress,RemotePort,State,OwningProcess # 2. 根据 PID 反查进程路径和启动参数 Get-CimInstance Win32_Process | Where-Object { $_.ProcessId -in 1234,5678 } | Select-Object ProcessId,ParentProcessId,Name,ExecutablePath,CommandLine # 3. 查看本机近 24 小时 4624 登录事件，重点看 LogonType 3/10 $start = (Get-Date).AddHours(-24) Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624; StartTime=$start} | ForEach-Object { $xml = [xml]$_.ToXml() [PSCustomObject]@{ TimeCreated = $_.TimeCreated TargetUser = ($xml.Event.EventData.Data | Where-Object {$_.Name -eq 'TargetUserName'}).'#text' LogonType = ($xml.Event.EventData.Data | Where-Object {$_.Name -eq 'LogonType'}).'#text' IpAddress = ($xml.Event.EventData.Data | Where-Object {$_.Name -eq 'IpAddress'}).'#text' ProcessName = ($xml.Event.EventData.Data | Where-Object {$_.Name -eq 'ProcessName'}).'#text' } } | Where-Object {$_.LogonType -in 3,10} | Format-Table -AutoSize # 4. 在被访问主机上查询服务创建事件，常用于识别 PsExec 类行为 Get-WinEvent -FilterHashtable @{LogName='System'; Id=7045; StartTime=$start} | Select-Object TimeCreated,ProviderName,Message # 5. 查询 PowerShell 远程执行痕迹 Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-PowerShell/Operational'; Id=4103,4104; StartTime=$start} | Select-Object TimeCreated,Id,Message 关键日志怎么看日志来源重点事件判断要点Security4624看 LogonType、源 IP、账号名，LogonType 3 常见于 SMB 网络登录Security4625短时间大量失败可能是口令验证或喷洒行为System7045远程服务创建，需关注服务名、二进制路径PowerShell Operational4103/4104查看是否有远程执行、下载执行、编码命令WMI-Activity5857/5858/5861确认是否有远程 WMI 查询或执行如果发现某账号在 5 分钟内从同一源 IP 登录多台服务器，且目标主机随后出现 7045 服务创建事件，这条链路就比较完整：源主机发起连接、账号完成网络登录、目标机创建服务。即便没有恶意文件，也至少说明存在远程管理或横向验证行为。本次案例中的结论示例经过日志对齐后，发现 10.10.20.15 上有一个运维脚本进程在 01:10 启动，启动账号为 svc_deploy。该脚本会批量检查 10.10.30.0/24 服务器的共享目录和服务状态。目标主机存在 4624 Type 3 登录，但没有 7045 服务创建、没有 4104 异常命令，也没有新增计划任务。所以本次不能直接判定为攻击者横向移动，更准确的表述是：在授权测试时间窗口内发现应用服务器对多台内网主机存在 SMB/RPC 批量访问行为，经日志核验，访问由运维服务账号 svc_deploy 发起，未发现远程服务创建、PowerShell 远程执行或异常文件写入证据。该行为更符合运维巡检脚本特征，但暴露出服务账号权限边界过大、网络访问控制过宽的问题。风险与修复建议收敛服务账号权限：svc_deploy 不应具备跨网段访问大量服务器的默认权限，按业务系统拆分账号和授权范围。限制横向访问面：应用服务器默认不应访问全网段 445、135、5985，仅保留必要目标和端口。启用更完整的审计：建议开启 PowerShell Script Block Logging、Module Logging，以及命令行审计。对高危事件建规则：4624 Type 3 短时间多目标登录、7045 服务创建、异常 WinRM 连接都应进入告警。区分运维与测试窗口：渗透测试期间应登记源 IP、测试账号、时间段，避免后续溯源时无法归因。防火墙或安全组可以先按最小化策略收敛，例如只允许应用服务器访问明确的数据库、缓存、日志服务器，而不是放通整个内网段。# Windows 防火墙示例：限制本机对内网 SMB 的出站访问，仅允许指定文件服务器 New-NetFirewallRule -DisplayName "Block outbound SMB to internal" ` -Direction Outbound ` -Protocol TCP ` -RemotePort 445 ` -RemoteAddress 10.10.0.0/16 ` -Action Block New-NetFirewallRule -DisplayName "Allow SMB to file server" ` -Direction Outbound ` -Protocol TCP ` -RemotePort 445 ` -RemoteAddress 10.10.30.10 ` -Action Allow 总结问答中心里遇到“疑似横向移动”这类问题，建议不要只凭端口或单条告警下结论。比较稳妥的方式是建立证据链：源主机进程、账号登录、目标主机事件、网络连接、运维变更记录。能闭环的才定性，不能闭环的要写清楚已验证范围和剩余风险。从渗透测试角度看，这类问题的价值不只是确认有没有被打，更重要的是发现权限边界和访问控制是否过宽。很多内网风险不是来自某个单点漏洞，而是来自服务账号、网络放通、日志缺失三者叠加。 服务器、云资产与权限边界梳理示意
周六 18:582天前 确认“疑似内网横向移动”建议先别急着下结论，按时间线把“账号、源主机、目标主机、协议、执行痕迹”串起来。授权测试里最好把证据链留完整，后面复盘和修复都更容易。 1. 先确认是否存在横向登录/远程执行 Windows 环境重点看这些事件： 4624：成功登录，关注 LogonType 4625：失败登录，排查撞库/密码喷洒 4672：特权登录 4688：进程创建，需要开启命令行审计才有价值 7045：新服务安装，常见于 PsExec 类横向 4697：服务安装 5140/5145：SMB 共享访问，例如 ADMIN$、C$ 1102：日志被清除 常见横向特征可以这样判断： LogonType=3：网络登录，常见 SMB/WMI/远程服务 LogonType=10：RDP 登录 LogonType=9：显式凭据，常见 runas /netonly 或工具传入凭据 短时间内同一账号访问多台主机，尤其是管理员账号 源地址不是堡垒机、运维机，却对多台主机访问 ADMIN$/C$ 目标主机出现临时服务、计划任务、远程进程执行痕迹 可以在目标机上快速拉取关键日志： wevtutil qe Security "/q:*[System[(EventID=4624 or EventID=4625 or EventID=4672 or EventID=4688 or EventID=5140 or EventID=5145 or EventID=1102)]]" /f:text /c:100 wevtutil qe System "/q:*[System[(EventID=7045 or EventID=7036)]]" /f:text /c:100 wevtutil qe Microsoft-Windows-TaskScheduler/Operational "/q:*[System[(EventID=106 or EventID=140 or EventID=141 or EventID=200 or EventID=201)]]" /f:text /c:100 如果有 PowerShell 日志，建议看： wevtutil qe Microsoft-Windows-PowerShell/Operational /f:text /c:100 wevtutil qe Microsoft-Windows-PowerShell/Operational "/q:*[System[(EventID=4103 or EventID=4104)]]" /f:text /c:100 2. 区分几类常见横向方式 不同方式留痕不一样，建议按这个思路排： 方式 常见痕迹 RDP 4624 LogonType=10，TerminalServices 日志，源 IP 明确 SMB/PsExec 4624 LogonType=3，ADMIN$ 访问，7045 服务安装，例如 PSEXESVC 或随机服务名 WMI 4624 LogonType=3，WMI-Activity 日志，目标进程常见 wmiprvse.exe 拉起 WinRM 5985/5986 连接，PowerShell Operational 日志，wsmprovhost.exe 计划任务 TaskScheduler Operational 106/140/200/201，任务名、执行命令可追 在目标机上可以补充看网络连接和最近进程： netstat -ano | findstr "445 3389 5985 5986 135" tasklist /v sc query type= service state= all schtasks /query /fo LIST /v 如果环境里有 Sysmon，会更好确认。重点看： Event ID 1：进程创建 Event ID 3：网络连接 Event ID 7：模块加载 Event ID 10：进程访问，排查凭据读取 Event ID 11：文件创建 Event ID 13：注册表修改 3. 建议保留的证据 授权测试报告里不要只写“疑似横向移动”，最好保留这些字段： 源主机名、源 IP、源账号 目标主机名、目标 IP 发生时间，统一时区 使用协议：SMB/RDP/WMI/WinRM/计划任务等 对应事件 ID 和原始日志截图/导出文件 是否使用高权限账号 目标机上产生的服务名、任务名、进程名、文件路径 是否访问了 ADMIN$、C$、敏感共享目录 导出日志可以这样做，便于交付和复盘： wevtutil epl Security C:\Temp\Security.evtx wevtutil epl System C:\Temp\System.evtx wevtutil epl Microsoft-Windows-PowerShell/Operational C:\Temp\PowerShell.evtx wevtutil epl Microsoft-Windows-WMI-Activity/Operational C:\Temp\WMI.evtx wevtutil epl Microsoft-Windows-TaskScheduler/Operational C:\Temp\TaskScheduler.evtx 如果需要采集登录会话： query user qwinsta net session net use klist sessions 4. 修复和加固建议 修复建议要和确认到的横向路径对应，不建议只写“修改密码”。可以分层处理： 账号层面：排查被用于横向的账号，重置密码，检查是否属于本地管理员、域管理员、远程桌面用户组。 本地管理员：启用 LAPS 或 Windows LAPS，避免所有机器本地 Administrator 密码相同。 远程访问：限制 RDP/WinRM/SMB 只允许堡垒机、运维网段访问。 凭据保护：开启 Credential Guard，禁用 WDigest 明文缓存。 日志审计：开启 4688 命令行记录、PowerShell Script Block Logging、Module Logging。 共享访问：审计并限制 ADMIN$、C$ 使用范围，普通运维不应跨网段直接访问。 最小权限：业务账号不要加入本地 Administrators，域管账号不要登录普通服务器。 几个常用加固项示例： :: 禁用 WDigest 明文缓存 reg add HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential /t REG_DWORD /d 0 /f :: 开启进程命令行审计，需要配合本地/域策略 reg add HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Audit /v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1 /f :: 查看 WinRM 状态 winrm enumerate winrm/config/listener :: 如非必要，关闭 WinRM winrm delete winrm/config/listener?Address=*+Transport=HTTP 防火墙层面建议明确限制管理端口来源，例如只允许堡垒机访问： netsh advfirewall firewall add rule name="Allow RDP From Bastion" dir=in action=allow protocol=TCP localport=3389 remoteip=10.10.10.10 netsh advfirewall firewall add rule name="Block RDP Others" dir=in action=block protocol=TCP localport=3389 netsh advfirewall firewall add rule name="Allow SMB From AdminSubnet" dir=in action=allow protocol=TCP localport=445 remoteip=10.10.20.0/24 netsh advfirewall firewall add rule name="Block SMB Others" dir=in action=block protocol=TCP localport=445 5. 报告里的结论写法 建议用“已确认/高度疑似/无法确认”三档，不要把单条日志直接定性成横向移动。例如： 已确认：源主机 A 使用账号 X 通过 SMB 登录目标主机 B，随后创建服务 Y 并执行命令 Z，日志包含 4624、5145、7045、4688。 高度疑似：账号 X 在 5 分钟内从同一源 IP 访问 8 台主机的 ADMIN$，但目标机进程日志缺失，无法确认具体执行内容。 无法确认：仅有一次 4624 LogonType=3，缺少共享访问、进程、服务或计划任务证据，暂不能判断为横向移动。 这样写比较稳，既能避免误报，也能给甲方明确的整改方向。
创建帐户或登录后发表意见