授权内网渗透中发现疑似 SMB 横向痕迹，如何定位来源并给出修复建议

背景

最近在一次授权内网渗透复盘里，客户安全设备提示某台 Windows 服务器存在 SMB 横向连接异常。问题本身不复杂，但在问答中心经常能看到类似疑问：只看到 445 连接告警，怎么判断是正常运维、漏洞验证、口令喷洒，还是已经发生横向移动？

这里按一次比较典型的排查流程整理，重点放在授权测试、日志定位、边界确认和修复建议，不讨论未授权攻击方法。

场景：内网域环境，疑似受影响主机为 FILE-SRV01，域控为 DC01，日志保留完整，测试方有客户授权的域普通账号和部分服务器本地管理员权限。

问题定位

初始现象是 IDS/EDR 给出如下线索：

• 源地址：10.10.20.34
• 目的地址：10.10.30.18，主机名 FILE-SRV01
• 目的端口：445/TCP
• 行为：短时间内多次 SMB Session Setup，部分失败
• 时间窗口：2024-xx-xx 14:21:00 到 14:27:00

这类告警首先不要直接下结论。SMB 访问可能来自文件共享、域策略、备份、补丁分发、运维脚本，也可能来自口令尝试、远程服务创建、计划任务或远程执行框架。

技术分析

排查时建议同时看三类证据：网络连接、Windows 安全日志、服务与计划任务痕迹。

其中比较关键的是登录类型。Windows 4624 事件里 Logon Type 为 3，通常表示网络登录，经常出现在 SMB 访问中。如果同时看到 4648，说明有进程使用了显式凭据访问远程资源，排查价值更高。

另外，5140/5145 里如果出现 ADMIN$、C$、IPC$，并不一定代表攻击，但如果紧跟着 7045 服务创建、4688 执行异常命令，就需要重点关注。

操作步骤

• 先固定时间窗口，避免在全量日志里盲查。
• 在目的主机 FILE-SRV01 上查 4624、4625、5140、5145、7045。
• 在源主机 10.10.20.34 上查 4648、4688、PowerShell 日志、Sysmon 网络连接。
• 确认使用的账号是否属于正常运维账号，是否在授权测试清单里。
• 把账号、源 IP、目标主机、共享路径、命令行串起来形成时间线。

代码/命令示例

下面这组 PowerShell 命令适合在有授权的情况下快速提取目标服务器上的关键日志。时间需要按实际告警窗口调整。

$start = Get-Date "2024-01-01 14:15:00"
$end   = Get-Date "2024-01-01 14:35:00"

$ids = 4624,4625,4648,5140,5145,7045

Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = $ids
    StartTime = $start
    EndTime   = $end
} | Select-Object TimeCreated, Id, ProviderName, Message |
    Format-List

如果日志量较大，可以按事件 ID 分开查。例如先看失败登录 4625，确认是否存在口令喷洒或错误凭据反复尝试：

Get-WinEvent -FilterHashtable @{
    LogName='Security'
    Id=4625
    StartTime=$start
    EndTime=$end
} | ForEach-Object {
    $msg = $_.Message
    [PSCustomObject]@{
        Time = $_.TimeCreated
        Account = ([regex]::Match($msg, 'Account Name:\s+([^\r\n]+)').Groups[1].Value).Trim()
        SourceIP = ([regex]::Match($msg, 'Source Network Address:\s+([^\r\n]+)').Groups[1].Value).Trim()
        Status = ([regex]::Match($msg, 'Status:\s+([^\r\n]+)').Groups[1].Value).Trim()
    }
} | Sort-Object Time | Format-Table -AutoSize

如果怀疑通过远程服务方式执行命令，可以查 System 日志里的 7045：

Get-WinEvent -FilterHashtable @{
    LogName='System'
    Id=7045
    StartTime=$start
    EndTime=$end
} | Select-Object TimeCreated, Message | Format-List

典型需要关注的字段包括 Service Name、Service File Name、Account Name。如果 Service File Name 指向临时目录、ADMIN$ 复制路径，或者命令行里包含 powershell、cmd /c、rundll32、regsvr32 等，需要进一步核验。

排查判断点

• 只有 5140 访问普通业务共享：多半是正常文件访问，但仍需核对账号和业务时间。
• 大量 4625 且来源单一：更像错误凭据循环、脚本配置错误或口令尝试。
• 4624 Type 3 后紧跟 5145 访问 ADMIN$：说明存在管理共享访问，需继续看是否有落地文件。
• 出现 7045：需要重点核查是否存在远程服务创建，这是横向执行链路中常见痕迹。
• 源主机有 4648：说明某个进程显式使用了凭据访问远程主机，可结合 4688 查父进程。

一个常见时间线示例

14:21:08  FILE-SRV01  4624  LogonType=3 Account=svc_backup Source=10.10.20.34
14:21:09  FILE-SRV01  5140  ShareName=\\*\IPC$
14:21:11  FILE-SRV01  5145  ShareName=\\*\ADMIN$ RelativeTargetName=temp\check.exe
14:21:14  FILE-SRV01  7045  ServiceName=checksvc ImagePath=C:\Windows\temp\check.exe
14:21:18  FILE-SRV01  4688  Parent=services.exe NewProcess=C:\Windows\temp\check.exe

如果在授权测试中出现上述链路，报告里应该明确说明这是测试行为还是异常行为。如果不是测试计划内操作，就需要进入应急流程：隔离源主机、保全日志、核验账号凭据使用范围。

风险与修复建议

• 限制管理共享访问：不要在普通办公网段开放到服务器网段的 445，至少按运维跳板机白名单控制。
• 收敛本地管理员权限：避免同一组本地管理员口令在多台服务器复用，可使用 LAPS 或等效方案。
• 拆分服务账号权限：备份、发布、监控账号不要混用，禁止交互式登录，限制登录到指定主机。
• 开启关键审计：建议启用登录、对象访问、进程创建、命令行记录，PowerShell 开启 Script Block Logging。
• 监控高风险事件组合：4624 Type 3 + ADMIN$ + 7045，比单独看 445 连接更有判断价值。
• 清理遗留测试文件：授权测试结束后，检查 ADMIN$、C$、Temp、计划任务、临时服务，避免测试痕迹长期存在。

Windows 审计策略可以参考下面的配置方向，实际需结合域策略统一下发：

auditpol /set /subcategory:"Logon" /success:enable /failure:enable
auditpol /set /subcategory:"Logoff" /success:enable /failure:enable
auditpol /set /subcategory:"File Share" /success:enable /failure:enable
auditpol /set /subcategory:"Detailed File Share" /success:enable /failure:enable
auditpol /set /subcategory:"Process Creation" /success:enable /failure:disable

reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Audit" /v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1 /f

总结

问答中心里这类问题的关键不是“445 告警是不是攻击”，而是把日志证据按时间线串起来。建议优先确认三件事：谁从哪里登录、访问了什么共享、是否触发了远程执行。

在授权渗透测试场景下，所有结论都应能回溯到具体事件 ID、主机名、账号和时间点。这样既能说明测试链路，也方便客户落地修复：收敛权限、限制横向通道、补齐日志审计。

这种场景建议先把“SMB 横向痕迹”拆成两件事定位：是谁发起连接、用什么凭据/方式成功访问。不要只看目标机上的 4624，容易漏掉源头进程和凭据来源。

1）在被访问的文件服务器/目标主机上确认 SMB 登录来源

优先查这些事件：

• 4624：登录成功，重点看 Logon Type = 3，以及 IpAddress、Account Name、Authentication Package
• 5140：访问了共享资源，能看到具体共享名
• 5145：详细文件共享访问，需要开启对象访问审计后更有价值
• 4672：特权账号登录
• 7045：远程创建服务，常见于 PsExec / Impacket psexec 类横向

可以先用 PowerShell 快速筛：

Get-WinEvent -FilterHashtable @{
  LogName='Security';
  Id=4624;
  StartTime=(Get-Date).AddDays(-7)
} | Where-Object {
  $_.Properties[8].Value -eq 3
} | Select-Object TimeCreated,
  @{n='Account';e={$_.Properties[5].Value}},
  @{n='Domain';e={$_.Properties[6].Value}},
  @{n='SourceIP';e={$_.Properties[18].Value}},
  @{n='AuthPkg';e={$_.Properties[10].Value}},
  @{n='Workstation';e={$_.Properties[11].Value}} | Format-Table -Auto

如果发现来源 IP 是某台办公机或跳板机，再回到那台机器继续查。

2）在来源主机上查“谁发起了 SMB 连接”

如果现场还在，可以先看当前连接和进程：

netstat -ano | findstr ":445"
Get-NetTCPConnection -RemotePort 445 | Select LocalAddress,RemoteAddress,State,OwningProcess
Get-Process -Id <PID>

如果已经结束，看 Sysmon 会更准。重点是：

• Sysmon Event ID 3：网络连接，目标端口 445
• Sysmon Event ID 1：进程创建
• Sysmon Event ID 10：进程访问，排查 lsass 读取
• Sysmon Event ID 11：文件创建，排查落地工具

筛选 445 连接示例：

Get-WinEvent -FilterHashtable @{
  LogName='Microsoft-Windows-Sysmon/Operational';
  Id=3;
  StartTime=(Get-Date).AddDays(-7)
} | Where-Object {
  $_.Message -match 'DestinationPort: 445'
} | Select TimeCreated, Message

常见可疑进程包括 cmd.exe、powershell.exe、wmic.exe、psexesvc.exe、rundll32.exe、未知路径下的 exe，或者 Python/Go 编译工具。若看到 ADMIN$、C$、远程服务创建，基本可以按横向移动链路处理。

3）区分正常管理行为和攻击行为

建议把时间线串起来：

• 目标机 4624 Type 3 登录时间
• 同一时间段是否有 5140/5145 访问 ADMIN$、C$、IPC$
• 是否紧接着出现 7045 远程服务安装
• 来源主机是否出现异常进程连接 445
• 账号是否在短时间访问多台主机

如果是域环境，还要查域控上的认证日志：

• 4768/4769：Kerberos TGT/TGS 请求
• 4776：NTLM 认证

重点看同一账号是否从非惯常主机请求大量 cifs/hostname 服务票据。命令示例：

Get-WinEvent -FilterHashtable @{
  LogName='Security';
  Id=4769;
  StartTime=(Get-Date).AddDays(-7)
} | Where-Object {
  $_.Message -match 'cifs/'
} | Select TimeCreated, Message

4）修复和加固建议

如果确认存在异常 SMB 横向，建议不要只封端口，按下面顺序处理：

1. 隔离来源主机：先断网或放入隔离 VLAN，保留日志和内存现场，避免继续横向。
2. 重置相关凭据：涉及的本地管理员、域账号、服务账号都要改密；如果怀疑 Hash 泄露，单纯改普通用户密码不够，要关注本地管理员复用问题。
3. 禁用本地管理员密码复用：部署 LAPS / Windows LAPS。
4. 限制 SMB 访问面：工作站之间默认不应互通 445，只允许管理网段、文件服务器、域控必要访问。
5. 关闭不必要的管理共享或限制管理员共享访问：至少通过防火墙和本地策略限制。
6. 开启 SMB 签名，降低中间人和中继风险。
7. 关闭 NTLM 或逐步限制 NTLM，至少先审计 NTLM 使用情况。

Windows 防火墙可以先做工作站侧限制，只允许管理网段访问 445：

New-NetFirewallRule `
  -DisplayName "Allow SMB from Admin Subnet" `
  -Direction Inbound `
  -Protocol TCP `
  -LocalPort 445 `
  -RemoteAddress 10.10.10.0/24 `
  -Action Allow

New-NetFirewallRule `
  -DisplayName "Block SMB from Other Subnets" `
  -Direction Inbound `
  -Protocol TCP `
  -LocalPort 445 `
  -Action Block

启用 SMB 签名可通过组策略配置：

Computer Configuration
  Windows Settings
    Security Settings
      Local Policies
        Security Options
          Microsoft network server: Digitally sign communications (always) = Enabled
          Microsoft network client: Digitally sign communications (always) = Enabled

5）几个容易被忽略的点

• 如果看到 NTLM 认证，优先排查是否存在 NTLM relay 条件，比如 SMB 签名未开启、LDAP 签名未开启。
• 如果来源主机是运维机，要查是否有凭据缓存、脚本内明文密码、计划任务账号。
• 如果多个目标都被同一账号访问，要优先判断该账号是否为域管或高权限服务账号。
• 如果日志缺失，至少补上 Sysmon、PowerShell Script Block Logging、文件共享审计，否则后续很难复盘。

最终报告里建议给出一条完整链路：来源主机 → 来源进程 → 使用账号 → 访问目标 → 访问共享/创建服务 → 影响范围。这样修复建议才不会停留在“关闭 SMB”这种泛化结论上。