做安全这行十几年，我越来越强烈地感觉到一个变化：以前分析一个木马样本，重点看它怎么落地、怎么写启动项、怎么连服务器；现在再看一个入侵事件，落地文件可能压根不存在，磁盘上干干净净，日志里全是"合法"操作。围绕 2024 到 2026 这个时间段复盘木马病毒的演变轨迹，最有价值的不是记住几个样本家族的名字，而是看清攻击手法这条主线怎么从"广撒网"走到"精耕细作"。下文为了合规，把标题里提到的两个标志性样本家族统一用 A 家族、B 家族代称，重点放在手法层面。这篇内容适合三类人看：一线做终端与流量应急的、做安全运营与检测规则工程的、以及负责架构与供应链安全的。不追求术语炫技，尽量把每一步"为什么这么设计"讲透，把能直接抄的检测思路和排查表格给到。

1. 先搞清楚演变的底层逻辑：为什么手法会一路"往下走"

1.1 成本收益账：攻击者其实一直在算投入产出比

很多人以为手法演变是"技术水平进步"，实际情况更像是"成本结构变化"。A 家族那个年代（大概十年前），终端防护能力弱，用户安全意识薄，最划算的做法就是批量投递、批量感染、批量变现，一个木马感染几十万台机器，靠的是规模。到了 B 家族所处的阶段，规模化投递的边际收益急剧下降：邮件网关拦得住、杀毒引擎认得样本哈希、沙箱能把可疑附件跑一遍。于是最经济的选择变成了"少而准"——定向投递、人工挑选目标、用合法工具完成动作。

这就解释了一个现象：单看某个入侵事件的样本数量，反而是变少的；但单个事件造成的损失和处置难度，是变大的。因为攻击者把预算从"数量"挪到了"隐蔽性"和"驻留时间"上。驻留时间越长，横向移动越充分，最终能拿到的数据越值钱。你做防御时如果还按"抓样本"的思路配资源，就会一直落在后面——他要的是不出声，你要的是他出声，这个博弈本身就不对称。

我个人的判断是，未来两年这个趋势会更明显：真正值钱的入侵会越来越像"正常运维"，检测的核心矛盾会从"识别恶意文件"变成"识别异常但合法的行为序列"。

1.2 三个不变的内核：入口、驻留、外联

手法再怎么变，攻击这件事有三个环节是绕不开的，我把它们叫做"三个铁三角"：

• 入口：必须有一个初始执行点，要么骗人点，要么骗系统跑。
• 驻留：必须活得比一次重启久，否则白干。
• 外联：必须有信息流出或指令流入，否则控制不了、也变现不了。

五年、十年前是这样，现在还是这样。变化只发生在每一环的"实现形式"上：入口从附件变成"业务上下文"，驻留从注册表启动项变成计划任务和服务，外联从固定 IP 变成云服务和伪装域名。你把这三个环节的观测点建齐了，哪怕以后出现全新的家族，也能照着这三条线去摸。

提示：做应急时最先看的三件事——谁第一个执行了可疑动作、它怎么活下来的、它在跟谁说话。这三件事的顺序不要乱，很多人一上来先抓样本做静态分析，结果驻留点没清干净，第二天又中了。

1.3 用杀伤链坐标把五大手法摆进去

把本文要讲的五大手法放到一条链上看，位置关系会清楚很多，也方便你在自己环境里对照检查"哪一段是空的"。

这张表我建议你直接贴在自己团队的看板上，因为大多数团队的实际短板会集中在 F3 和 F4——F3 是因为日志分散在身份系统里，没人天天看；F4 是因为"信任的东西默认不检查"，心理盲区。

2. 手法一：从群发垃圾到"定制剧本"的社工化投递

2.1 变化点不在话术，而在载体和上下文

十年前钓鱼邮件的典型特征是错别字多、排版粗糙、附件是个压缩包。现在的手法已经完全不同，核心变化有三个方向。

第一是载体的迁移。可执行文件附件早就过不了网关，于是搬到了容器类格式（镜像文件、虚拟磁盘文件）、快捷方式文件、以及"HTML 走私"——收到的是一个网页文件，打开后浏览器在本地把载荷"拼"出来再落盘。这类载体在网关眼里是数据不是程序，静态检测很难下判断。

第二是上下文的伪造。现在的高级投递会引用你公司真实存在的项目编号、真实的审批流程、真实的同事姓名和职位。这些信息来自公开渠道和此前泄露的数据。你收到一封"关于某某项目结算材料补充"的邮件，附件命名规范、语气专业，很容易就点了。

第三是回信劫持。攻击者拿到某个供应商邮箱后，直接在历史邮件线程里回复，加一个"更新版附件"。这种情况下连发件人域名都是真的，DKIM/SPF 全过。

我处理过的一个案例就是第三种：财务人员收到的邮件来自一个长期合作的供应商邮箱，线程完整可查，附件是"对账单更新版"。如果不是终端侧的命令行审计恰好记录到脚本宿主被拉起，这单很可能就过去了。

2.2 落地细节：为什么"点一下"就能执行

载体变了，但执行链路有几处是固定的，这几乎是所有投递手法的必经之路：

1. 用一个"用户认为正常"的程序打开载体（浏览器、阅读器、压缩工具、镜像挂载）。
2. 由这个程序派生出一个"不该由它派生"的子进程（脚本宿主、命令行解释器、控制台程序）。
3. 该子进程执行一段内容被编码或拼接过的命令。
4. 从网络拉取下一阶段内容，或者直接在当前进程内完成动作。

第 2 步是整条链里最有检测价值的一环，因为"父进程—子进程"的组合关系在正常业务里相对稳定。浏览器派生脚本宿主、阅读器派生命令行、办公软件派生控制台，这三种组合出现的时候，就值得看一眼了。

具体落地时我会做两步操作：先把过去 30 天全网的进程创建日志按"父进程名 + 子进程名"聚合出频次表，人工标注出前 50 个高频组合建立白名单基线；再对不在基线内的组合单独设告警。这一步看起来土，但效果比堆几十条规则要好。

// 思路示例：按父子进程组合聚合，找出低频组合 // 字段名按各家的日志模型自行映射 ProcessCreate | where TimeGenerated > ago(30d) | extend PairKey = strcat(ParentImage, " -> ", Image) | summarize Cnt = count(), Hosts = dcount(HostName) by PairKey | where Cnt < 5 and Hosts <= 2 | order by Cnt asc

2.3 注意事项：别把"检测"做成"拦所有"

这块有几个坑我踩过，直接说结论：

注意：不要一上来就阻断"办公软件派生命令行"。很多企业的模板、插件、报表工具就靠这个跑，一刀切下去业务先炸，然后规则被关掉，后面再也没人敢开。

比较稳的顺序是：先只记录不告警，跑两周看基线分布；再对高频业务路径做例外，例外要写明申请人和有效期；最后才上告警。告警分级上，把"办公软件派生脚本宿主且命令行含远程地址"设为高优先级，其余设为中低。

还有一个细节：邮件侧要盯的不只是"有没有恶意附件"，而是"首次出现的发件域名"和"账户行为突变"——比如一个长期只发文字邮件的外部联系人突然开始发带链接的邮件，这本身就是一个信号。

3. 手法二：无文件与内存加载，让磁盘保持"干净"

3.1 为什么攻击者偏爱内存

磁盘上不落地，意味着三件事同时成立：杀毒引擎扫不到、取证时没有样本、重启后痕迹自然消失（如果是纯内存型）。A 家族那个阶段还大量依赖落盘的可执行文件，到了 B 家族所处的阶段，加载器、载荷、配置几乎全在内存里完成，磁盘只留一个"看起来正常"的入口。

这类手法的实现路径可以抽象成三种，理解思路比记细节重要：

• 脚本内联：通过脚本宿主把远程内容下载到内存中直接执行，磁盘无文件。
• 进程注入：把内容写进另一个正常进程的内存空间，借它的身份运行，行为归属被混淆。
• 白利用与签名二进制代理执行：用系统自带的、有合法签名的可执行文件去做下载、执行、编码这些动作。这类程序本来就在系统里，签名有效，黑名单根本管不了。

第三种是最头疼的，因为它把"文件是否可信"这个问题彻底绕开了——文件本身完全可信，问题出在"谁在用它、用来干什么"。

3.2 关键观测点：把行为日志开全比写规则重要

这块我的经验是：规则质量的上限由数据源决定。没有命令行审计，你写再多规则也只能看到"某个程序被启动了"，看不到它干了什么。所以我做这件事的第一步永远是盘数据源，而不是写规则。

必须打开的四类审计：

• 进程创建审计（含完整命令行、父进程、执行账户）
• 模块加载审计（尤其是从非磁盘路径加载的模块）
• 脚本执行审计（脚本块内容、调用者）
• 网络连接审计（进程到目的地址的映射关系）

其中"进程到目的地址的映射"是最容易被忽略但价值最高的一项。因为不管前面怎么混淆，最终都要连出去。你能把"哪个进程连了哪个地址"对上，很多无文件手法就露馅了。

3.3 实操：用基线代替枚举

枚举式的思路是"我知道有哪些可疑程序"，这条路永远走不完。基线式的思路是"我知道正常情况下是什么样的"，偏离即告警。我一般做三层基线：

第三层里有个实用技巧：把"进程名 + 目的域名的新鲜度"组合起来看。一个系统进程连了一个注册不到 30 天的域名，这个组合的可疑度远高于单独看域名新旧。域名新鲜度数据可以从公开的域名注册信息里拿到，成本不高。

提示：命令行审计会带来可观的日志量，务必在采集端做好字段裁剪和采样策略，否则存储成本会先把你劝退。我的做法是保留完整命令行但只存 90 天，同时把含敏感参数的命令行单独加密归档。

4. 手法三：凭据窃取与横向移动，一次进来全网开花

4.1 战场已经转移到身份层

这是近五年最大的一次重心转移。早期木马的目标是"控制机器"，现在的目标是"拿到身份"。原因很直接：机器只是一个点，身份是一张网。拿到高权限身份，攻击者根本不需要在每台机器上装东西，直接用合法远程管理通道走过去就行，行为看起来跟运维一模一样。

凭据获取的常见落点就那么几个：内存中残留的认证材料、本地保存的凭据文件、票据缓存、以及配置文件中明文存放的口令。这几处的共同点是"系统为了方便而留下的东西"，本身不是漏洞，是设计取舍。你不去主动收敛，它就一直敞着。

4.2 横向移动的三种"合法外衣"

手法上，横向移动几乎都披着合法外衣：

• 远程服务与共享通道：用系统自带的远程管理能力推送内容、创建服务。
• 票据滥用：不破解口令，直接复用已有的认证票据，绕过口令校验环节。
• 身份系统层面的操作：在目录服务里做权限变更、加账户、改属性，一步到位拿长期权限。

第二类最容易被漏掉，因为它不产生"登录失败"这种显眼信号，全程都是成功的认证记录。你要看的是"认证发生的时间、来源、目标是否合理"，而不是"认证是否成功"。

4.3 关键日志与检测对照表

这张表里我要特别强调第四行。很多入侵事件的"最后一锤"就是在目录服务里加了个高权限账户，然后安静地用。这个动作本身在日志里只是一条普通的变更记录，如果你没有人事流程联动，根本发现不了。

4.4 收敛优先于检测

说句实话，凭据这块最好的处置不是检测，是收敛。我按投入产出比排了个序，你可以照这个顺序做：

1. 清掉不必要的本地特权账户，把本地管理员账户的唯一化、随机化做到位。
2. 限制高权限身份的可登录范围，高权限账户不允许登录普通办公终端，这条能挡掉很大一部分横向。
3. 缩短票据有效期并开启票据绑定校验，让被窃取的票据难以异地复用。
4. 把口令保管纳入流程，禁止在脚本和配置文件中明文存放。

第 2 条我见过太多企业做不到，原因是"运维图方便"。但这条的价值极高——高权限账户一旦不能随便登录终端，攻击者从终端跳到核心系统的路就断了。

5. 手法四：信任链滥用，绕开一切检测的那条路

5.1 为什么这条最难防

前面三种手法，你还有机会在"行为"层面抓它。信任链滥用不一样，它污染的是"判断依据"本身。你信任一个软件的签名，攻击者就用有签名的组件；你信任更新通道，攻击者就劫持更新通道；你信任依赖库，攻击者就往依赖里投毒。B 家族所代表的那类事件之所以杀伤力大，就是因为它从"可信渠道"发出来的，所有基于"来源是否可信"的检测全部失效。

这里有个认知要纠正：签名只证明"是谁签的"，不证明"内容安全"。很多时候我们把第一件事当成了第二件事。

5.2 三条常见的滥用路径

• 更新通道劫持：在正常的升级链路中插入一环，让合法软件自己把恶意内容拉进来。这种情况下终端侧看到的是"自家软件在升级"，行为完全正常。
• 构建环节污染：在源代码管理、构建流水线、制品仓库任意一环动手，产物在出库时就已经不干净了。这类问题最隐蔽，因为出问题的位置离"被发现的现场"很远。
• 依赖投毒：往公开依赖库里发布名字相近或版本号更高的包，等着构建时被自动拉进来。名字相似这一招尤其有效，靠人眼几乎分辨不出来。

5.3 可落地的验证清单

这块我整理了一份自查清单，你可以直接拿去对照：

第三行是我认为性价比最高的一条。签名主体变更是一个低频事件，正常软件几乎不会换签名主体，所以这个信号的信噪比极高。你不需要复杂的分析，只要在每次更新时比对一下主体指纹就行。

另外提一句构建环境隔离。我见过的最惨的一类事故是构建机被当成跳板，攻击者从构建机拿到了制品仓库的发布凭据。构建机通常是"权限高、监管弱"的典型，因为它不面向用户，安全团队很少把它当资产看待。

注意：不要为了"稳定"给依赖固定一个"永远不升级"的版本。那样确实躲过了投毒，但也躲过了补丁。正确做法是锁定版本 + 定期评审升级 + 升级前核验哈希。

6. 手法五：低调持久化与伪装外联

6.1 持久化的"隐身"选择

持久化这件事，攻击者的选择标准只有一个：噪音最小。A 家族时代常见的做法是往注册表启动项里塞东西，这个动作现在几乎等于自曝。取而代之的是几类更安静的位置：

• 计划任务：尤其是带触发条件的、名字伪装成系统组件的任务。普通管理员看任务列表时，一眼扫过去很难分辨。
• 系统服务：伪装成驱动或系统组件，启动类型设置为延迟启动，避开开机高峰。
• 系统管理规范的订阅机制：这类持久化非常隐蔽，因为它不产生文件也不产生服务，只在特定事件触发时执行。
• 账户层面的持久化：直接留一个"看起来正常"的账户，或者给已有账户加一个不常用的登录方式。这类最容易被忽视，因为大家查持久化都在查机器，不查身份。

我印象最深的一次，是把一台机器的文件、服务、任务全清完之后，攻击者第二天又回来了。最后发现入口是一个三个月前创建的计划任务，名字伪装成了某个系统维护组件，触发条件是"用户空闲 10 分钟后"。这种条件触发型的任务，日常巡检根本注意不到。

6.2 外联隐蔽化的四个方向

外联这块的演变方向很明确：混进正常流量。具体有四个方向：

第一是借用公共云服务。把指令和数据的交换藏在常见的云存储、协作平台、代码托管服务的正常请求里。这类流量的目的域名信誉良好，流量看起来完全正常。

第二是域名伪装。用与被仿冒对象高度相似的域名，或者干脆在正常域名前面加多层子域，让肉眼扫过时以为是自己人。

第三是协议走私。把数据封装在 DNS 查询、常见协议的正常字段里。DNS 出站几乎不会被拦，所以这条路一直有人走。

第四是加密直连加指纹伪装。让 TLS 握手特征尽量接近常见浏览器，使得基于指纹的识别失效。

6.3 检测思路：从"看域名"转向"看关系"

面对这四个方向，靠域名黑名单是没戏的。我的思路是转向关系分析，具体三步：

第一步，建立"主机—目的"的二部图。正常主机的对外关系是相对稳定的，一个财务的电脑不会突然去连一个数据分析平台。偏离这个图就是要看的地方。

第二步，关注"周期性"。很多持久化外联是定时心跳，表现为极规律的时间间隔。用简单的统计方法就能把"每 60 秒一次、误差极小"的连接挑出来。这个特征比内容检测稳健得多。

第三步，观察数据流向的失衡。上传量远大于下载量，或者请求体积固定、响应体积固定，这类模式在正常业务里少见。

# 检测逻辑示意：周期性外联识别 rule: periodic_beacon_like_connection logic: group_by: [host, dst_domain] window: 6h condition: - connection_count > 60 - interval_stddev < 3s # 间隔高度规律 - distinct_payload_size <= 3 # 请求体积高度一致 action: escalate_to_analyst false_positive_hint: - 监控探针、心跳上报、时间同步

最后那个误报提示很重要。监控探针和心跳上报的行为跟木马心跳几乎一模一样，如果你不先把这类资产标记出来，告警会被瞬间淹没。

7. 把五大手法串成一条能跑的检测流水线

7.1 数据源盘点：先看有没有，再看准不准

我见过太多团队，规则写得漂亮，但数据源是断的。所以这件事的第一步永远是盘点，我一般用一个简单的四象限法：按"有没有采"和"采了用没用"分类。落在"采了没用"这一格的通常是身份认证日志和 DNS 日志——量太大，没人看；落在"没采"这一格的通常是构建系统和制品仓库的日志。

7.2 一组能跑起来的检测逻辑

规则数量不是关键，关键是每条规则都能回答"我为什么设这个阈值"。下面这组是我常用的骨架，参数需要按你的环境重调。

D2 里的"高熵字符串"要解释一下：正常命令行里的参数通常有固定词汇，而编码后的内容字符分布更随机。用简单的熵值计算就能区分，不需要复杂模型。这个指标比"有没有 base64 关键字"稳健得多，因为攻击者早就不用那个关键字了。

7.3 告警分级与响应动作

告警分级不是为了让报表好看，是为了让人力分配有依据。我的分级标准是这样的：

• P0：同时命中 D1 + D4，或者命中 D3 + D7。这类组合意味着"执行 + 扩散"或"加载 + 外联"，基本可以判定为真实事件，直接启动应急。
• P1：单独命中 D1、D3、D4。需要 30 分钟内人工确认。
• P2：命中 D2、D6、D8。进入当日分析队列，聚合后判断。
• P3：D5、D7 单独命中。周维度复盘，找趋势。

这套分级的核心思想是"组合优于单点"。单个信号误报率高，但两个不同环节的信号同时出现，误报率会大幅下降。这也是为什么我一直建议把检测规则按"环节"而不是按"样本家族"来组织——按样本组织，新家族出来你就要重写；按环节组织，新家族只是换了个形式走进同一个观测点。

8. 常见问题与排查技巧实录

8.1 一线高频问题速查表

8.2 几个反直觉的坑

坑一：以为没日志就是没发生。我遇到过一台机器，进程审计没开，只剩网络连接日志。后来靠"这台机器连了一个非常规的 443 端口且上传量异常"这个信号才摸到线索。这件事之后我养成了一个习惯：应急处置时先问"我们有哪些数据"，而不是"我们应该看到什么"。

坑二：过度依赖文件哈希。哈希只能识别已知样本，一改就失效。真正稳定的识别特征是行为序列和上下文关系，比如"谁启动的、用什么账户、连了哪里、什么时候执行的"。

坑三：把清除当成处置终点。清完恶意文件、重启、确认干净——这个流程只解决"这一次"。如果不能回答"他是从哪进来的"，那大概率还会有下一次。我现在的习惯是，任何一起事件必须产出两个东西：一个根因结论，一个能落地的加固项，否则不算结案。

坑四：忽略"非技术"的观测面。有些入侵的最早信号不在日志里，而在业务流程里——比如某个审批流程突然多了一个环节，某个账户突然开始处理不属于它的单据。这类信号需要和业务方建立沟通渠道才能拿到。

8.3 怎么验证自己真的防住了

最后分享一个我常用的验证方法：用假设驱动的演练代替工具扫描。具体做法是挑一个手法，写出"如果攻击者用这种方式进来，我会在哪几个观测点看到什么"的清单，然后去日志里查这几个点有没有数据、数据能不能支撑判断。

比如针对 F2，我的清单是三条：

1. 我能看到浏览器派生出的子进程吗？——查进程创建日志的父子关系字段是否完整。
2. 我能看到脚本的具体内容吗？——查脚本块审计是否开启，能否关联到发起进程。
3. 我能把一个网络连接归因到具体进程吗？——查网络日志里有没有进程标识字段。

这三条只要有一条答"不能"，那么对应的检测规则就是虚的。这种验证方式比跑一遍扫描器有用得多，因为它验证的是"能力"而不是"配置"。

我个人在实际操作中的体会是，做威胁对抗这件事，最怕的不是技术不够，而是观测面不全却不自知。样本会变、家族会换名字、手法会继续演化，但只要你把入口、驻留、外联这三段的观测点建扎实，把身份这条线守住，把信任链的验证流程跑起来，新东西进来的时候你至少能看见它，而不是等它走了才发现地上有脚印。