企业官网建设流程全解析

• 网络安全

本指南基于 Sliver Adversary Emulation Framework 的monitor命令组（client/command/monitor/README.md），讲解如何利用内置的 Watchtower 能力，将植入体（Implant）构建哈希与 VirusTotal、IBM X-Force 等威胁情报平台进行周期比对，从而判断植入体是否已被安全厂商捕获（Burned）。读完本文，你将掌握monitor命令的完整用法、服务端配置方式，以及从客户端命令到服务端扫描循环、事件发布的完整调用链。

Watchtower 功能概述

Sliver 服务端内置了一个名为 Watchtower（瞭望塔）的监控子系统：周期性把服务器上生成过的所有植入体构建（Implant Build）的 MD5 哈希提交到 VirusTotal 与 IBM X-Force，检测这些构建是否已经被上传到威胁情报平台。一旦某个构建的哈希被命中，该构建就会被标记为Burned，并触发watchtower事件推送给控制台，提醒操作者该植入体已不再安全。

该能力在文档 docs/sliver-docs/pages/docs/md/Watchtower.md 中有明确定义，属于 Sliver 服务端的内置能力，而非第三方扩展。从 server/watchtower/watchtower.go 的源码可以看到，其核心循环基于第三方库github.com/lesnuages/snitch实现。

monitor 命令组结构与注册

monitor命令组位于 client/command/monitor/，共四个 Go 源文件，职责划分如下：

命令注册入口在 commands.go：monitor根命令被分配了consts.SliverHelpGroup帮助分组，并挂载两个子命令：

• monitor start—— 启动监控循环；
• monitor stop—— 停止监控循环。

命令名常量定义在 client/constants/constants.go（MonitorStr = "monitor"、MonitorConfigStr = "config"）。整个命令组通过 client/command/server.go 中的monitor.Commands注册进客户端命令树，与 sessions、jobs 等命令组并列。

服务端配置：server.json 的 watch_tower 段

使用监控功能前，需要在 Sliver 服务端配置文件中写入威胁情报平台的 API 凭据。官方文档 docs/sliver-docs/pages/docs/md/Watchtower.md 给出的配置片段如下：

{ "watch_tower": { "vt_api_key": "YOUR_VIRUSTTOTAL_API_KEY", "xforce_api_key": "YOUR_XFORCE_API_KEY", "xforce_api_password": "YOUR_XFORCE_API_PASSWORD" } }

配置文件位于$HOME/.sliver/configs/server.json，修改后需重启 Sliver 服务端生效。配置结构体定义在 server/configs/server.go：

// WatchTowerConfig - Watch Tower job config type WatchTowerConfig struct { VTApiKey string `json:"vt_api_key" yaml:"vt_api_key"` XForceApiKey string `json:"xforce_api_key" yaml:"xforce_api_key"` XForceApiPassword string `json:"xforce_api_password" yaml:"xforce_api_password"` }

• vt_api_key：VirusTotal API Key（必填，若启用 VirusTotal 扫描）；
• xforce_api_key：IBM X-Force API Key；
• xforce_api_password：IBM X-Force API 密码（仅 X-Force 需要，对应代码中apiType == "xforce"时的APIPassword字段）。

字段同时带有json与yaml标签，说明服务端配置同时兼容 JSON 与 YAML 两种格式。服务端配置测试 server/configs/server_config_test.go 覆盖了旧版（legacy）JSON 配置向新格式迁移后watch_tower段被正确加载的完整路径，包括旧配置文件被备份、新 YAML 配置生成的迁移行为，可作为排查配置加载问题的参考。

monitor 命令的完整用法

monitor start / monitor stop

在控制台（console）中输入monitor start即可启动监控，monitor stop停止监控。二者的实现非常简洁：

• start.go 调用con.Rpc.MonitorStart(ctx, &commonpb.Empty{})，成功后打印Started monitoring threat intel platforms for implants hashes；
• stop.go 调用con.Rpc.MonitorStop(ctx, &commonpb.Empty{})，成功后打印Stopped monitoring threat intel platforms for implants hashes。

monitor config（配置管理辅助）

虽然官方文档仅提及start/stop两个子命令，但从源码看 config.go 中还实现了配置的增删查逻辑（命令名config常量见 constants.go）：

• MonitorConfigCmd：调用MonitorListConfigRPC，将当前已保存的监控配置以表格形式输出（列为 ID、Type、APIKey、APIPassword），渲染逻辑见PrintWTConfig（config.go）；
• MonitorAddConfigCmd：通过--apiKey、--apiPassword、--type三个 Flag 构造clientpb.MonitoringProvider，当type == "xforce"时额外填充APIPassword，然后调用MonitorAddConfigRPC（config.go）；
• MonitorDelConfigCmd：先列出全部配置，再通过forms.Select交互式选择要删除的配置（selectWatchtowerConfig，config.go），随后调用MonitorDelConfigRPC。

注意：这些 config 子命令在当前commands.go中并未直接挂载到monitor根命令下，源码中保留的 API 级配置管理逻辑配合start/stop构成了完整的生命周期控制；实际使用时以你所用版本控制台输出的帮助信息为准。

服务端调用链与实现原理

RPC 层

客户端的所有 monitor 操作最终都会落到 server/rpc/rpc-monitor.go 中的四个 gRPC 方法，它们直接代理到 watchtower 包：

其中MonitorStart会先通过ListConfig读取当前已保存的 provider 凭据，再启动扫描器，因此必须先完成配置（配置文件或运行期添加）才能成功启动监控；否则StartWatchTower会返回 "missing provider credentials" 错误。

对应的 protobuf 消息定义位于 protobuf/clientpb/client.proto：

// watchtower message MonitoringProviders { repeated MonitoringProvider providers = 1; } message MonitoringProvider { string ID = 1; string Type = 2; string APIKey = 3; string APIPassword = 4; }

数据库层的MonitoringProvider模型定义在 server/db/models/monitor.go，Type字段注释明确指出当前仅支持vt或xforce两种类型。

Watchtower 核心循环

监控的核心实现在 server/watchtower/watchtower.go，其启动流程StartWatchTower（第 65-100 行）包括：

1. 检查watcher是否已初始化，已启动则返回 "monitoring already started"；
2. 检查configs.Providers是否为空，为空返回 "missing provider credentials"；
3. 遍历 provider：Type == "vt"创建snitch.NewVTScanner(APIKey, VTMaxRequests, "Virus Total")；Type == "xforce"创建snitch.NewXForceScanner(APIKey, APIPassword, XForceMaxRequests, "IBM X-Force")；
4. 若扫描器列表为空，同样返回 "missing provider credentials"；
5. 通过snitch.WithHandleFlagged(handleBurnedImplant)注册命中回调，AddScanner逐个加入扫描器后watcher.Start()启动循环；
6. 调用addExistingImplants()把数据库中已有的、未标记 Burned 的植入体构建逐个加入监控名单（update函数按 MD5 加入 watch list）。

命中回调handleBurnedImplant（第 30-46 行）是监控的"收尾"动作：

• 通过db.ImplantBuildByName(result.Sample.Name())找到对应构建，将Burned置为true并持久化；
• 遍历core.Sessions.All()，若会话名与样本名一致，则通过core.EventBroker.Publish发布consts.WatchtowerEvent事件，事件 Data 形如"<Provider> - <LastSeen>"，包含命中的平台名称与最近出现时间。

Burned字段定义在植入体构建模型 server/db/models/implant.go，注释明确其含义："has been seen on threat intel platforms"（已在威胁情报平台出现）。这解释了监控的完整业务闭环：发现命中 → 标记 Burned → 发布事件 → 操作者收到警报。

停止流程StopWatchTower（第 106-112 行）则调用watcher.Stop()、重置initialized并将watcher置空，保证可以再次monitor start。

请求频率限制

官方文档 docs/sliver-docs/pages/docs/md/Watchtower.md 明确说明：服务端会自觉保持在各平台免费额度之下，即：

• VirusTotal：4 次请求/分钟，500 次请求/天（对应snitch.VTMaxRequests）；
• IBM X-Force：6 次请求/小时（对应snitch.XForceMaxRequests）。

这一设计确保长期运行的监控循环不会因为超出免费额度而触发平台的 API 限流或封禁。

与反应（Reaction）机制的联动

watchtower事件可以作为 Reaction（反应）的触发条件，实现自动化告警。在 client/command/reaction/commands.go 中，consts.WatchtowerEvent被注册为可用的反应事件类型；事件类型常量定义在 client/constants/constants.go：

// WatchtowerEvent - An implant hash has been identified on a threat intel platform. WatchtowerEvent = "watchtower"

事件的人类可读名称在 client/command/reaction/reaction.go 中映射为"Watchtower Trigger"。因此，操作者可以配置类似reaction watchtower <自定义命令>的规则，在植入体哈希被威胁情报平台发现的第一时间自动执行后续动作，例如通知值守人员或更换植入体构建。此外，client/command/help/long-help.go 与 client/command/ai/grpc_test.go 中对该事件类型的引用，也印证了它作为标准客户端事件流的一员被广泛消费。

常见问题排查

• monitor start报 "missing provider credentials"：服务端配置文件中watch_tower段缺失或为空，或数据库中尚无任何 provider 配置。请检查$HOME/.sliver/configs/server.json的watch_tower字段并重启服务端；也可以尝试通过 config 管理逻辑（MonitorAddConfigCmd对应 RPC）在运行期添加凭据。
• monitor start报 "monitoring already started"：监控循环已在运行，无需重复启动；如需重启，先执行monitor stop。
• 监控已启动但始终没有命中：请确认数据库中确实存在已构建的植入体记录（addExistingImplants只会把已存在且未 Burned 的构建加入名单）；同时注意 VirusTotal 免费额度（4 次/分钟、500 次/天）与 X-Force 的 6 次/小时限制，首次全量比对可能需要较长时间。

小结

Sliver 的monitor命令组把"植入体是否被安全厂商识破"这件威胁情报工作自动化了：配置好 VirusTotal / IBM X-Force 凭据后，一条monitor start即可让服务端周期性比对所有植入体构建的哈希，命中时自动标记 Burned、推送watchtower事件，并可联动 Reaction 实现告警。从 commands.go 的命令注册、start.go 与 stop.go 的 RPC 转发，到 server/watchtower/watchtower.go 的扫描循环与命中回调，整条链路清晰可控，是红队对抗演练中检查植入体暴露面的实用内置工具。

• 网络安全