内网横向痕迹与跳板机行为分析

内网横向痕迹与跳板机行为分析

在很多应急事件中，最危险的并不是攻击者进来，而是他进来之后开始在内网移动。一旦一台主机被拿下并被用作跳板，事件就会迅速从单点失陷升级为域内扩散、业务联动失控，甚至演变为勒索、批量投毒或大范围数据泄露。

0x02电子取证 已经给了很多横向相关的证据入口，例如 系统用户审查、异常端口查询、系统共享检查、服务信息检查。但这些证据在现场往往是碎片化的：某个账号登录过、某个端口连过、某个共享被访问过。到了 0x03取证分析，真正重要的是把这些碎片拼成一条链，回答：

• 这台主机只是受害者，还是已经被转化为跳板
• 攻击者通过哪种协议、用什么身份在内网移动
• 横向是试探、扩点，还是已经形成稳定中继
• 哪些主机是源头、哪些主机是二跳节点、哪些主机只是被扫到

0x01 横向分析先看“角色”，不要急着看“协议”

很多现场一看到 445、3389、22、5985 就开始判断横向，但更有效的做法是先判断每台主机在事件中的角色。

1. 入口主机

这类主机的特征通常是：

• 先出现外部入侵、钓鱼、WebShell、木马回连
• 随后出现对内连接和资产枚举

它是攻击链的起点，但未必是唯一跳板。

2. 中继主机

这类主机最关键的特征不是“被访问过”，而是“被访问之后又开始访问别人”。常见表现是：

• 先有入站登录或控制
• 紧接着出现多台内网目标的出站连接
• 后续出现工具投放、代理、中转或批量远程执行

这种主机才是分析中的重点，因为它决定了影响面如何扩散。

3. 末端受害主机

这类主机通常只表现为：

• 被某个跳板访问
• 出现远程服务、任务、进程或共享访问
• 自身没有继续向外扩散

如果把它误判成跳板，会错误估计攻击者的控制能力。

4. 诱饵或被扫主机

并不是所有被连接过的主机都真的被拿下。很多主机只是：

• 被端口探测
• 被尝试认证
• 共享被触碰但未成功
• 有短暂连接但没有后续执行结果

因此横向分析的第一步，不是统计可疑连接数量，而是给资产定角色。

0x02 怎么判断一台主机已经变成跳板

跳板判断不是看“有没有对内连接”，而是看它是否完成了从受控节点到中继节点的角色转换。

1. 最强判断点：外来控制之后立刻出现对内动作

如果一台主机在以下事件之后：

• 外部登录成功
• WebShell 落地
• 远控木马上线
• 本地高权限被拿下

紧接着又开始：

• 连接多台内网主机
• 访问管理共享
• 发起 SSH / RDP / WinRM
• 投放服务、任务、脚本

那么它就很可能已经成为跳板。这里最关键的是“前后时序”，不是某一条孤立日志。

2. 次强判断点：同一身份在该主机上被用于继续扩散

如果：

• 某个账号先在主机 A 上登录
• 随后 A 使用同一账号去访问 B、C、D
• 目标主机上又留下成功执行痕迹

那么主机 A 的角色就不再是普通受害机，而是身份复用和横向发起点。

3. 补强判断点：主机出现明显中转工具或代理能力

例如：

• frp、nps、socat、lcx、chisel
• SSH 本地、远程或动态转发
• SOCKS 代理
• 批量远程执行工具

这类痕迹出现时，说明攻击者不是只做“一跳”，而是在建设稳定的内网作业面。

0x03 横向分析的核心不是“协议名”，而是“动作语义”

不同协议背后代表的攻击目的并不一样。分析时要从协议推回动作语义。

1. SMB / 管理共享

如果只看到 445 连接，意义其实很弱；真正关键的是它后面发生了什么：

• 只是探测和列共享
• 还是访问了 ADMIN$、C$、IPC$
• 是拷贝载荷，还是单纯读取文件
• 随后有没有服务创建、计划任务或可执行文件落地

也就是说，SMB 在分析里通常是“投送”和“准备执行”的前奏。

2. RDP

RDP 的语义更偏“人工交互控制”。如果某个高权限账号在多台主机上连续出现短时会话，往往说明攻击者正在人工切换节点、核实环境、挑选后续目标。

3. SSH

SSH 在 Linux 环境里既可能是正常运维，也可能是最典型的横向方式。判断关键不在 22 端口本身，而在：

• 来源主机原本是否有权访问这些目标
• 登录后是否伴随密钥扩散、脚本投送、端口转发
• 多台主机上是否出现同一私钥、公钥或相同命令模式

4. WinRM / WMI / PsExec / 远程服务

这类方式的共同点是“非交互式远程执行”。它们更像自动化批量横向，尤其常见于：

• 勒索前批量投放
• 域控后清点资产
• 短时间对大量主机执行统一命令

因此一旦出现远程服务、远程任务、批量进程拉起，就要优先怀疑攻击者已经完成从单点控制到规模化扩散的转换。

0x04 身份分析决定你能否重建横向路径

攻击者横向移动时，最常用的未必是新建账号，而是复用已有身份。很多误判都出在只盯着“新增用户”，却忽略了“老账号被异常复用”。

1. 真正应该重点看的身份

• 域管理员
• 本地管理员
• 运维、发布、备份账号
• 数据库服务账号
• 远程桌面用户
• SSH 私钥拥有者

2. 横向分析里，身份要回答四个问题

这个身份平时是否就该出现在这里

如果某个 DBA 账号出现在数据库主机很正常，但出现在文件服务器、办公终端和跳板外的应用节点，就要提高警惕。

这个身份的时间点是否异常

凌晨、节假日、非变更窗口、告警后数分钟内出现的新登录，都比白天固定运维时段更值得关注。

这个身份是“被使用”还是“被接管”

例如：

• 凭据抓取之后立即出现多台主机上的同账号登录
• 同一账号源地址短时间快速切换
• 同账号同时在多地、多节点出现

这更像认证材料被盗用，而不是账号本人正常操作。

这个身份是否驱动了后续扩散

一个账号即便有一次异常登录，也未必意味着横向成功；但如果它接着驱动 SMB、RDP、SSH、WinRM、服务创建、任务投送，那它就是横向主线身份。

0x05 如何从连接还原“方向”和“意图”

0x02 里看连接，通常是找异常端口；0x03 里看连接，重点是还原方向和意图。

1. 先分清谁是发起者，谁是承受者

分析时至少要同步看四件事：

• 连接是入站还是出站
• 发起时间与登录时间谁在前
• 目标主机上是否出现执行结果
• 同一源是否继续访问更多目标

如果只看“谁连过谁”，但不看先后顺序，很容易把被扫主机误判成横向节点。

2. 再看连接后的“结果证据”

真正能让横向成立的，不是连接本身，而是连接后的结果：

• 共享访问成功
• 远程服务创建成功
• 任务投放成功
• 目标主机出现新进程、新文件或新登录

没有结果证据的连接，更多只能定性为试探、探测或尝试。

3. 最后看它是否形成“扇出”

当一台主机出现如下模式时，通常就是典型跳板：

• 先被控
• 后对多台主机发起相同或相近协议连接
• 多个目标主机上出现一致的执行结果

这就是横向分析里最有价值的“扇出模型”。

0x06 三类最容易误判的场景

1. 正常运维与恶意横向

两者都可能表现为：

• 多主机登录
• 共享访问
• 远程执行
• 高权限账号出现

真正的差异在于：

• 是否有工单、变更窗口、固定目标范围
• 是否使用稳定脚本和标准化流程
• 是否伴随扫描、试错、清痕、提权、下载、代理

正常运维强调“可解释性”，攻击者行为更像“逐步扩点和试探”。

2. 跳板机与普通业务中转节点

某些应用网关、堡垒机、中间件节点本来就会对多主机建立连接。不能只因为它连接很多内网主机就判定为跳板。

要重点看：

• 是否存在异常来源先控制了它
• 它是否在异常时间出现新的横向协议
• 是否出现与原业务无关的共享、RDP、SSH、WinRM 行为

3. 被扫到与被攻陷

很多资产只留下端口连接或认证失败记录，没有后续执行结果。这类主机应该归入“探测或尝试目标”，而不是直接写成“已失陷节点”。

0x07 公开案例最值得借鉴的横向分析视角

案例一：Petya/NotPetya 一类事件里的“批量横向”特征

公开报告中，Petya/NotPetya 一类事件非常典型地展示了 SMB、PsExec、WMI 等方式如何把单点入侵迅速放大为全网扩散。对分析人员来说，这类案例最重要的价值不是记住某个家族名，而是记住其链路特征：

• 先拿到高权限认证材料
• 再利用远程执行协议快速扇出
• 多台目标主机留下相似的服务创建和远程执行痕迹
• 扩散节奏高度一致，且目标范围迅速扩大

这类链路一旦成立，说明现场不能再按“单主机事件”处置，而要立即切换到“域内扩散事件”视角。

案例二：WebShell 之后的二跳横向

Unit 42 对一些长期潜伏活动的公开分析里，多次出现“外网打入 Web 节点后，再借该节点向内网横向”的模式。其关键不是第一跳有多复杂，而是第二跳常常发生在看似正常的业务主机之间。

这个案例对现场的启发是：

• 对外应用节点一旦被打入，必须沿着它的内网访问能力继续追
• 数据库主机、文件服务器、发布机、堡垒机往往是第二阶段目标
• 只盯着入口点会低估影响范围

案例三：云与混合环境中的横向并不一定走传统域协议

Unit 42 关于云环境横向的公开研究提醒了一点：横向不一定全靠 445、3389 或域控。很多时候，攻击者会通过管理凭据、API、跳板主机、自动化脚本在混合环境里完成“逻辑横向”。这意味着分析时不能把视野只停留在传统 Windows 域事件。

对混合环境来说，横向分析还要补充判断：

• 被控节点是否兼具云管理、CI/CD、数据库、发布能力
• 横向是否通过密钥、令牌、自动化脚本而不是人工交互实现
• 资产之间的“信任关系”是否比网络连接本身更关键

0x08 命令结果和事件结果怎样解释成横向结论

横向分析真正有价值的积累，是把“命令输出 / 日志结果”翻译成“横向是否成立、是否成功、哪台是跳板”。下面这些经验更适合直接写进实战文章。

1. 4624(LogonType=3) + 4672 不是直接等于横向成功，而是“高权限网络登录候选”

例如在目标主机上执行：

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624,4672} |
  Select-Object TimeCreated, Id, Message

如果结果中出现：

Event ID: 4624
Logon Type: 3
Account Name: domain\admin
Source Network Address: 10.10.20.15

Event ID: 4672
Special privileges assigned to new logon
Account Name: domain\admin

更合理的判定是：

• 已出现一次高权限网络登录，具备横向前提
• 这说明目标主机接受了来自 10.10.20.15 的管理型访问
• 但仅凭这两条还不能写成“横向成功执行”，因为还缺少共享访问、服务创建、进程执行等结果证据

Splunk 在横向检测实践里一直强调 4624 + 4672 更适合作为横向候选起点，而不是终局结论，这个边界很重要。

2. 5140/5145 命中 ADMIN$、C$、IPC$，再接 7045/4698，才是更完整的 SMB 横向链

如果你在目标主机上看到：

5140: A network share object was accessed
Share Name: \\*\ADMIN$
Account Name: domain\admin
Source Address: 10.10.20.15

几分钟内又出现：

7045: A new service was installed on the system
Service Name: PSEXESVC
ImagePath: C:\Windows\PSEXESVC.exe

或者：

4698: A scheduled task was created
Task Name: \UpdateTask
Author: domain\admin

这时候分析结论就可以明显上升：

• 先有管理共享访问，说明目标主机已被用于文件投送或远程管理准备
• 随后有远程服务或计划任务创建，说明已从“访问共享”进入“触发执行”
• 如果 ServiceName 是 PSEXESVC 或异常随机名，几乎就可以把它归入 PsExec / 服务型横向范畴

MITRE 的 SMB Admin Share 检测策略也明确强调，ADMIN$/C$ 访问后再接远程执行事件，才是最值得优先关注的多事件关联。

3. 7045 的 ImagePath 在非常规目录，比单纯“新服务创建”更有定性价值

如果命令结果或日志里看到：

Event ID: 7045
Service Name: updater_3421
ImagePath: C:\Windows\Temp\updater.exe
Start Type: demand start

相比普通“某服务被安装”，更应直接判定为：

• 服务执行载荷落在临时目录，恶意概率明显高于系统目录
• 这类路径更像横向时临时投放的可执行文件，而不是正式软件安装
• 如果前序还有 5140/5145 管理共享访问，基本可以串成“共享投送 -> 服务执行”的横向链

Splunk 和 Elastic 的预置检测都把“7045 + 非标准 ImagePath”视为服务型横向的重要落点，因为它直接回答了“远程执行是否真正落地”。

4. 源主机出现 PsExec.exe 网络连接，目标主机再出现 PSEXESVC，就不再只是工具使用，而是双端闭环

如果在源主机进程或网络里看到：

Process: PsExec.exe
Destination Port: 445
Destination Host: APP-02

目标主机同时或随后看到：

Event ID: 7045
Service Name: PSEXESVC

更好的分析写法是：

• 源端表明攻击者确实从该主机发起了 PsExec 行为
• 目标端表明远程执行组件已经在对端安装
• 双端证据同时成立时，可以把 WS-01 -> APP-02 明确写成一条成功的服务型横向路径

Elastic 关于 PsExec 和 SMB 横向的调查指南也强调，要同时看源端进程、网络连接和目标端服务/文件事件，单端证据容易误判。

5. Linux 上 known_hosts 快速新增，不等于横向成功；要配合 auth.log 和命令历史看

如果现场命令结果是：

stat ~/.ssh/known_hosts
tail -n 20 ~/.ssh/known_hosts
grep "Accepted " /var/log/auth.log | tail -n 20
history | egrep 'ssh|scp|rsync'

结果表现为：

known_hosts 在 03:11 被修改
新增 10.0.0.21、10.0.0.35、10.0.0.52
03:12 出现 Accepted publickey for appuser from 10.0.0.18
history 中出现 scp tool.tar.gz 10.0.0.21:/tmp/

那么判定逻辑应是：

• known_hosts 新增只说明有人尝试建立 SSH 信任，不代表已经成功横向
• Accepted publickey 或 Accepted password 才说明某一跳认证成功
• scp、rsync、脚本投送命令出现后，说明事件已从“登录成功”进入“工具或载荷转移”
• 如果该主机此前本是 Web 服务器而非运维跳板，这种组合就非常接近“受害节点转跳板节点”

6. WebShell 命令结果里出现 plink、wmic、copy \\host\ADMIN$，语义比单个命令名更重要

公开案例里，攻击者常通过 WebShell 执行：

plink -R 3389:127.0.0.1:3389 ...
wmic /node:APP-02 process call create "cmd /c whoami"
copy beacon.exe \\APP-02\ADMIN$\Temp\

面对这种结果，分析时应分别判定为：

• plink -R / plink -L：说明在建设隧道或中继，不只是普通远控
• wmic /node:：说明正尝试或已经对远端发起 WMI 远程执行
• copy ... \\host\ADMIN$：说明正在通过管理共享做横向投送

Unit 42 对 xHunt / BumbleBee 的分析就展示了攻击者如何通过 WebShell 命令和隧道行为推进横向。真正有用的沉淀，不是“攻击者用过 plink”，而是“看到这类参数，就要把主机角色从受害点提升为中继点候选”。

0x09 一条完整的横向链应该怎样落笔

横向分析的结果，不建议只写成“发现若干主机间存在 445/3389/22 连接”。更适合的写法是：

1. 入口节点 哪台主机先被控，控制方式是什么。
2. 主线身份 哪个账号、密钥或令牌驱动了后续横向。
3. 第一跳 从哪台主机通过什么协议到达哪个目标，结果是否成功。
4. 第二跳与扇出 哪台主机从受害节点转变为中继节点，并继续扩散。
5. 最终影响 哪些主机只是被探测，哪些主机已被执行，哪些主机被转化为新的跳板。

这套结构能直接支撑封堵优先级排序：先断主线身份，再隔离中继节点，最后回收末端受害主机。

0x0A 建议的交付表

横向移动分析最好整理成“源 -> 目标 -> 方式 -> 身份 -> 结果”的表：

这样能很直观地展示：

• 横向从哪里开始
• 中间哪台主机变成了跳板
• 影响面扩散到哪些资产
• 哪些节点只是尝试命中，哪些节点已确认执行成功

0x0B 总结

横向移动分析的关键，不是证明“这台主机有几个可疑连接”，而是要证明：

• 哪个身份在驱动这些连接
• 连接具有怎样的方向和目的
• 哪些连接只是试探，哪些已经形成执行结果
• 是否伴随共享访问、服务创建、远程执行、代理或进一步扇出
• 哪台主机已经从受害节点转化为跳板机

当你把 系统用户审查、异常端口查询、系统共享检查、服务信息检查 这些分散证据拼成一条“入口 -> 身份 -> 协议 -> 结果 -> 二跳扩散”的链路时，内网横向分析才真正从 0x02 的排查动作，升级为 0x03 的攻击路径重建能力。