mythic_telegram_profile

通过Telegram机器人间消息隧道传输Athena和Apollo代理流量的Mythic C2配置文件，将加密载荷通过其Push C2 gRPC服务桥接到Mythic。

对于本地开发，改为安装检出目录：

在同一个 Mythic 部署中安装一个受支持的 agent fork：

Telegram 设置

1. 使用 @BotFather 创建控制器 bot。
2. 为每个将同时运行的 payload 实例创建一个单独的 bot。
3. 为控制器 bot 和每个 agent bot 启用 Bot 到 Bot 通信模式。
4. 记录控制器 bot token 和用户名。
5. 记录每个 agent bot token。不要为并发 payload 复用 token，因为 getUpdates 消费者共享同一个更新队列。

私有 bot 到 bot 消息要求两个 bot 都启用通信模式。Telegram 在其 Bot 到 Bot 通信 指南中记录了该要求。

配置 C2 服务

在 Mythic 中，打开 C2 Profiles，展开 telegram 的操作，然后选择 View/Edit Config。设置：

保存配置，然后启动该 profile。

构建 payload

在构建 Athena 或 Apollo 时选择 telegram C2 profile，并提供：

操作限制

• Bot API token 是一种 bearer 凭据。限制访问，并在使用后通过 BotFather 撤销它。
• Agent token 嵌入在 payload 中。将恢复的 payload 视为已泄露的 token。
• Telegram 传输不是端到端加密的。保持启用 AESPSK。
• Telegram 会保留消息元数据，并可能根据其服务政策保留消息内容。
• 此 profile 使用长轮询，而不是 webhook。
• 单个 bot token 不得由并发 agent 实例共享。它们的 getUpdates 调用会相互消耗对方的响应。
• 控制器只接受由 bot 编写的、带版本号的传输信封。Mythic 加密仍然提供消息认证和机密性。
• Agent 请求会保持挂起，直到相关的控制器响应到达。重试的请求复用相同的请求标识符，控制器会重放缓存的响应，而不会将重复流量转发给 Mythic。
• Mythic 可以在没有 agent 请求挂起时推送任务。控制器会将该任务排队，并将其与 agent 的下一次交换相关联，而不是将其丢弃。
• 在三次错过的最大抖动回调间隔加上 30 秒后，控制器会将路由报告为断开连接，最小超时为 60 秒。

线路格式

每条 Telegram 文本消息包含一个带有以下字段的 JSON 对象：

• v：协议版本，当前为 1
• sender_id：由 agent 进程生成的随机路由标识符
• client_id：响应路由标识符
• to_server：方向标志
• packet_id：块集合标识符
• reply_to：由控制器响应确认的请求标识符
• sleep：当前 agent 回调间隔，以秒为单位
• jitter：当前 agent 回调抖动百分比
• chunk：从零开始的块索引
• chunks：总块数，限制为 256
• message：加密的 Mythic 消息片段

不完整的块集合会在十分钟后过期。