4.2 主机端点检测：进程链与内存迹象

4.2 主机端点检测

本节摘要：网络侧说"这台机器在跟外面说话"，主机侧回答"是谁在说、说了什么"。本节讲主机端点上的三类证据——进程链、内存迹象、行为清单——以及把它们互相印证的读法。这是 4.5 节主机侧复盘案例的方法论底座。

为什么主机侧是"内容层"的主场

网络加密把内容锁住了，主机侧却恰恰相反：动作发生在哪里，证据就留在哪里。会话在主机上要依附一个进程存在（自带的调度进程，或注入的宿主进程），任务执行会产生子进程、文件接触、账户验证、注册表读写——这些动作在端点遥测里逐一留名。所以行业有个说法：网络侧看形状，主机侧看内容。两边拼起来，才是完整的叙事。

端点侧的证据有个鲜明特点：琐碎但具体。单条日志几乎都可有别的解释——一个进程启动可能是运维操作，一次凭据验证可能是用户登录。主机侧分析的全部功力，在于把琐碎的证据串成链、对着行为清单验形。下面分三块讲。

图 4-1 三类主机侧证据的互补关系

进程链：谁能叫出谁的名字

进程链是一台主机上"谁启动了谁"的谱系。读进程链有三条经典读法，各有适用与误判风险。读法一：出身异常。正常业务里，进程的父进程相对固定——办公文档由办公套件启动，构建任务由持续集成代理启动。若一条"系统工具"进程的父进程是办公文档解释器或临时目录里的程序，出身即疑点。误判风险：部分合法软件的启动方式本来就绕，基线里要为已知的"绕法"建档。读法二：位置异常。系统工具本该待在系统目录，若同样的工具名出现在用户可写目录，是经典的借名手法。这条几乎零误报，但只覆盖借名这一类。读法三：参数异常。同一工具带着与基线完全不同的参数组合出现，比如以非常规方式加载脚本引擎执行代码。参数分析误报率中等，需要与业务基线对照。

三条读法共享同一个底层思想：让进程回答"你为什么存在、谁叫你来的"。回答不了，就是候审对象。下面这段示意事件序列展示一条可疑链的形状：

时刻        事件                       父进程          进程            位置
09:41:12   文档打开                   explorer        winword        常规办公目录
09:41:47   子进程启动                 winword         cmd            用户临时目录
09:41:48   脚本解释器启动             cmd             powershell     系统目录 正常位置
09:41:52   网络访问                   powershell      -              目的为外部新地址
​

链的异常不在任何单行：文档打开正常，解释器本身正常，网络访问本身正常。异常在边上——文档解释器不该有命令行子进程，命令行不该一启动就碰外网。这就是进程链分析的本体：单点皆可解释，链条即告警。

把这段链变成日常能力，还有一步工程化要做：把"边"的定义写进基线。哪些父子组合在自家环境合法（构建代理拉起编译器）、哪些组合一律可疑（办公套件拉起命令行）、哪些组合需要上下文（脚本引擎访问网络）——三类关系在端点策略里配置成允许、禁止、审查三档。配置完成后，上面那段事件序列就不再依赖分析师的肉眼，端点产品会在第二条边出现的瞬间告警。肉眼读链是研判技能，配置基线是工程能力，两者要分开练：前者靠案例复盘（本章末两节），后者靠持续的基线维护。

内存迹象：落脚处的物理证据

会话无论以自带进程还是注入宿主的方式存在，其代码在内存中的存在形态与普通程序有别，这些差异就是内存迹象的来源。给防守者讲，重点不是注入手法本身（本书红线），而是注入的必然副产品：跨进程写入必留权限痕迹，在他人内存里展开代码必留无归属的内存段，规避托管层的执行方式必留解释器层面的形态异常。端点产品把这些副产品转成了几类高价值信号：被多个团队验证过的跨进程操作告警、内存段与磁盘文件不一致的校验类信号、以及脚本引擎的异常加载链。

对内存迹象的合理预期要摆正：它是高置信但非全域的观测面。覆盖依赖端点产品的部署率与版本，且部分动作在老系统上信号质量下降。所以内存迹象在研判中的角色是"定音锤"——当网络侧与进程链已有中等置信的怀疑时，内存迹象往往一锤定音；但它不适合当唯一的初筛手段，成本与覆盖都不允许。

行为清单：把证据对表

前两类证据是"原始痕迹"，行为清单是"形状模板"。第 1.4 节的术语对照表在这里升级为检测对表：把已知平台的典型行为序列列成清单——会话依附哪个类型的进程、任务执行时惯用哪类子进程、凭据采集习惯触碰哪些存储、横向移动偏好的协议门类——然后把现场证据逐条对表。对表的产出叫吻合度描述，注意措辞：写"行为序列与某类工具的典型形态吻合度较高"，而不是"确认是某工具"。这个措辞纪律在 1.3 节讲过：形态与本体要区分。对表的价值在缩小范围、指导下一步取证方向，不在盖棺定论。

对表时还有一个常被低估的维度：时间行为。清单不只列"做了什么"，还列"隔多久做"——会话的取件节律、任务执行的批次模式，都是清单字段。把主机侧观测到的进程活动时刻序列与网络侧的外联时刻序列并排，两列若逐行咬合，叙事就闭合了；若错位，要么有时钟问题（3.4 节的老朋友），要么说明观测面之间还有未发现的环节。这个"双列咬合"动作是 4.4 节案例里置信度跃升的实际来源，值得单独练熟。

三类证据的协同读法可以用一句话收拢：进程链给叙事，内存迹象给定夺，行为清单给方向。4.5 节的复盘案例将按这个次序完整走一遍。

常见疑问

问：没有商用端点产品，只有系统自带日志，还能做主机侧分析吗？
能做，深度打折。系统自带的进程创建审计、脚本块日志、PowerShell 日志，足以支撑进程链分析的大部分读法；开启审计策略的正确子项，是零采购条件下性价比最高的安全投资。内存迹象则基本依赖专用产品，没有就把它从初筛手段里去掉，只保留应急时的静态取证用途。

问：端点告警和网络告警经常互相矛盾，信谁？
先查时钟再谈矛盾——两套遥测的时间基准不一致是最常见的"矛盾"来源。对齐时钟后，矛盾本身就是线索：网络侧看见而主机侧没动静，查遥测覆盖盲区；主机侧动作明显而网络侧干净，查是否走了未观测的出口。两个"看不见"都指向基础设施问题，值得单独立项。