跳到主要内容

watchdog

在分析银狐（Silver Fox / ValleyRAT / Winos）这类木马时，很多人都会遇到一个很烦的现象：

明明已经把样本进程结束了，过一会儿它又起来了。

这种现象背后，常见就有一层所谓的 watchdog 逻辑。

但这里的 watchdog，通常不是某个固定文件名，也不是 Windows 官方里一个专门叫这个名字的组件，而更接近一种能力设计：

监视主进程是否还活着
↓
如果退出、崩溃、被结束
↓
重新拉起

所以在银狐语境里，把 watchdog 理解成“看门狗进程”或者“自恢复守护逻辑”，通常会更准确。

角色​

如果把银狐的整条执行链拆开看，watchdog 往往不是最开始的入口，也不是提权本身，而是一个保证木马别轻易掉线的中间层。

常见位置更像这样：

诱导执行 / 初始投递
↓
落地 Loader / RAT
↓
建立持久化
↓
watchdog 开始监视
↓
主进程被杀 / 崩溃 / 退出
↓
重新启动木马
↓
继续通信或继续后续动作

所以它的核心价值不是“提升权限”，而是：

提高驻留稳定性

换句话说，watchdog 更像是银狐持久化和驻留能力里的“保险丝”和“自动重启器”。

形态​

很多人第一次听到 watchdog，会下意识想成：

一个固定名字的守护进程

但在实际样本里，它未必长这样。

watchdog 可能表现为：

  • 一个单独的辅助进程，专门盯住主木马是否退出。
  • 两个恶意进程互相监视，谁死了另一个就把它拉起来。
  • 一个服务进程监视用户态载荷。
  • 一个计划任务、启动项、脚本或快捷方式，定时检查并重启木马。
  • 一个被注入的宿主进程，负责在内存里维持心跳和重启逻辑。

所以更准确的理解方式是：

watchdog
=
一组“监视 + 恢复”的机制

而不是执着于找一个名字就叫 watchdog.exe 的文件。

实现​

从用户态恶意样本常见做法看，watchdog 的实现并不神秘，很多都还是 Windows 本来就提供的能力拼起来的。

常见思路大致有几类。

进程互拉​

这是最容易理解的一类。

它可能表现成：

payload A 启动 payload B
↓
A 监视 B
↓
B 也记录 A 的状态
↓
任意一个退出
↓
另一个重新创建它

实现上常见会看到：

  • CreateProcess
  • OpenProcess
  • WaitForSingleObject
  • GetExitCodeProcess
  • 进程遍历与命令行重建

这类逻辑的优点很直接：

  • 实现简单。
  • 不依赖特别高的权限。
  • 主进程被手工结束后，恢复速度通常很快。

对防守方来说，这也是最常见的一种“刚杀掉又起来”的原因。

持久化恢复​

这种做法更偏持久化。

大致逻辑可以理解为：

木马主体退出
↓
服务 / 任务计划 / Run Key 仍然存在
↓
系统下一次触发时再次拉起

它和实时双进程监视不完全一样，因为它不一定做到“秒级复活”，但恢复更稳定。

在银狐这类强调长期驻留、反复上线的家族里，watchdog 往往会和这类持久化一起出现，而不是二选一。

也就是说，实际链路经常更像：

实时 watchdog
+
持久化兜底

这样即使辅助进程也被一起清掉，系统重启、用户登录或定时触发后，木马仍然有机会回来。

心跳监视​

有些样本不会简单地做：

WaitForSingleObject(进程句柄)

而是改成周期性心跳。

例如：

  • 定期写某个文件、注册表值或命名管道消息。
  • 使用命名事件、互斥体、共享内存交换状态。
  • 通过本地 socket / pipe 发送存活信号。

如果在设定时间内没有收到心跳，就认为主模块异常退出，然后执行重启。

这种方式的好处是更灵活，因为它监控的不只是“进程还在不在”，还可能包括：

  • 是否卡死。
  • 是否失去网络通信能力。
  • 是否被安全产品挂起。
  • 是否没有正常完成指定动作。

所以更高级一点的 watchdog，盯住的其实是“功能是否仍然正常”，不只是进程是否存在。

价值​

因为银狐很多阶段都很依赖稳定驻留。

只要它的目标还是：

  • 维持远控通道。
  • 等待操作者下发后续任务。
  • 做信息窃取、下载执行、横向移动或注入。
  • 在被用户察觉后尽量自行恢复。

那它就天然会希望自己别因为一次崩溃或一次手工结束就彻底掉线。

因此 watchdog 在这类家族里的现实意义非常强：

减少单点失败

如果没有它，攻击者会遇到很多很现实的问题：

  • 宿主进程崩了，整条链断掉。
  • 用户在任务管理器里结束一次进程，控制权没了。
  • 某个注入目标退出后，木马也跟着消失。
  • 安全软件做了部分处置，但没有彻底清理全部组件。

有了 watchdog 之后，银狐就更像是：

不是一个孤立进程
而是一套能自我恢复的小系统

与持久化的区别​

这两个概念经常被混在一起，但其实不完全相同。

可以粗略地区分成：

Persistence（持久化）
=
重启之后、登录之后、定时触发时还能回来
watchdog
=
当前这次运行没结束之前，尽量别轻易掉线

所以它们的关注点不同：

  • 持久化更关注“下次怎么回来”。
  • watchdog 更关注“这次别死，死了也立刻回来”。

在真正成熟一点的木马里，这两者通常是同时存在的。

检测​

如果你在主机上看到下面这些现象，就很值得往 watchdog 方向去想：

  • 同一路径下两个可疑进程互相拉起。
  • 结束一个进程后，另一个兄弟进程几秒内重新创建它。
  • 某个陌生服务的唯一作用就是不断启动另一个可疑程序。
  • 任务计划反复触发同一路径的样本。
  • 一个本不该具备守护职责的办公软件子进程，持续枚举进程、检查 PID、重建命令行。
  • 样本退出前后总伴随文件落地、注册表修复、快捷方式重建等恢复动作。

在遥测上，常见可以重点看这些组合：

CreateProcess
↓
目标进程异常退出
↓
短时间内被同源程序再次启动

或者：

进程被人工结束
↓
同目录下另一个样本立即启动它

单看一次 CreateProcess 没什么特殊，但如果它总在“同伴退出之后”发生，味道就不太对了。

处置​

因为很多人处理这类样本时，只盯着当前最显眼的那个进程。

但如果背后还有：

  • 辅助守护进程。
  • 计划任务。
  • 服务项。
  • Run Key。
  • 被替换的快捷方式或脚本启动器。

那你结束主进程，只是切掉了表层执行体，并没有切掉恢复机制。

所以处理思路通常不能是：

只杀当前进程

而更接近：

找出主进程
↓
找出谁在守护它
↓
找出谁负责重启
↓
把恢复链一起切掉

这也是为什么真实应急里，经常要把进程、父子链、服务、计划任务、注册表持久化项、落地目录一起看。

误区​

有些人会把 watchdog 理解成“特别高级的木马特征”，其实不完全对。

因为：

  • 很简单的脚本轮询也能算一种 watchdog。
  • 很普通的计划任务重复拉起也能达到类似效果。
  • 没有显式双进程守护，不代表样本就没有长期驻留能力。

所以判断重点不该是：

它是不是有一个名字很像 watchdog 的模块

而应该是：

它有没有一套在掉线后自动恢复的机制

攻击链位置​

如果把前面几篇内容连起来看，银狐的很多能力点其实都能串成一条线：

初始执行
↓
提权
↓
Enable SeDebugPrivilege
↓
注入 / Token Theft / 持久化
↓
watchdog 维持驻留
↓
被杀后再次恢复

所以 watchdog 在这条链里最适合被理解成：

不是攻击动作本身
而是保证攻击动作能持续存在的“存活层”

这也是为什么在银狐分析里，只盯着注入、提权、下载执行还不够，还要问一句：

它是怎么保证自己不轻易消失的？

很多时候，这个答案就是某种形式的 watchdog。