企业官网建设流程全解析

• 文档
• 教程
• 网络安全

Session 克隆是 Viper 红队平台中用于复制已上线权限的核心模块：一方面可以在一个 Session 掉线后确保权限不丢失，另一方面可以通过"虚拟监听 + Session 克隆"的组合，把已有权限快速迁移到 Cobalt Strike 平台实现双 C2 上线。本文依据 模块文档 完整梳理该模块的两种操作流程、前置条件与关键参数（如虚拟监听与 LURI），并补充虚拟监听原理、自动编排防死循环等实战要点，读完即可在真实渗透场景中直接落地使用。

Session 克隆能解决什么问题

该模块在官方文档中的定位十分明确：复制 Session，确保一个 Session 掉线后权限不丢失，或者用于迁移权限到 Cobalt Strike。

在实战中，这一需求几乎贯穿每一次内网渗透：

• 防掉线丢权限：操作 Session 的过程中，可能由于杀毒软件查杀、网络抖动、进程退出等原因导致 Session 掉线。在 信息收集教程 中官方建议：实战中先克隆生成多个 Session，再进行进一步操作，以免丢失权限。有了多个 Session 后，就可以大胆执行后续操作（横向移动、提权、抓取凭证等）而不用担心单点掉线导致权限全失。
• 双平台接管：把 Viper 中已有的 Session 迁移到 Cobalt Strike，实现权限在 Cobalt Strike 侧同步上线，方便在团队既有工作流中统一管理，或利用 Beacon 的稳定性继续推进后渗透。

前置条件：Session 克隆的两项硬性要求

在执行克隆前，需要同时满足两个条件，缺一不可：

也就是说，Session 克隆本质上是让目标主机基于当前 Session 的上下文，重新回连到指定监听生成一个新的权限，因此监听必须真实存在且可被目标主机访问。

操作一：Session 克隆（权限冗余备份）

标准克隆流程分为以下四步：

1. 确认存在 Windows 类型 Session：在主面板中查看已上线的 Session，确认存在 Windows 类型（x64 或 x86 均可）的权限；
2. 确认存在对应的真实监听：在监听（Handler）面板中确认已建立与目标 Session 相匹配的真实监听；
3. 打开 Session 克隆模块并选择监听：进入模块列表，打开Session克隆模块，在参数中选择本次克隆要使用的监听；
4. 执行模块：运行模块后，面板中就会出现一个新克隆出来的 Session，该新 Session 与原 Session 拥有相同的主机权限上下文，但以独立 Session 的形式存在。

实战中建议在拿到关键权限（如域管、高权限进程）后立即克隆 1～2 个副本，再继续高风险操作，这是 信息收集教程 中反复强调的"多 Session 冗余"思路。

虚拟监听：Session 克隆迁 C2 的核心概念

在进入"迁移 Cobalt Strike 上线"流程之前，必须先理解 Viper 的虚拟监听机制。根据 监听载荷指南 的定义：

• 虚拟监听是指将输入的监听配置选项存储在缓存中，但不在服务器中建立实际运行的监听。后续在运行模块、传输协议时可以快速选择该监听配置；
• 适用场景包括注入 shellcode、spawn 进程、AB 网正向 handler 等——只需要快捷调用已有监听配置，而不需要真正开放端口建立网络监听或网络连接；
• 虚拟监听与真实监听可相互转化（通过生成虚拟监听/生成真实监听按钮）；
• 虚拟监听在系统重启后仍然存在，可用于钓鱼模拟、持久化等场景；
• 界面区分：真实监听使用绿色图标表示，虚拟监听使用灰色图标表示。

理解这一点后就能明白：Session 克隆到 Cobalt Strike 的链路是——克隆出的新 Session 会去回连配置中指定的"监听"，而该监听的信息指向 Cobalt Strike 的 Teamserver 地址；由于回连行为由目标主机发起、由 CS 侧接收，Viper 侧不需要真的开放端口，因此用虚拟监听承载这段配置即可。

操作二：Cobalt Strike 上线（虚拟监听 + Session 克隆）

官方文档明确：Viper 可以通过虚拟监听 + Session 克隆的方式方便 Cobalt Strike 上线。完整流程如下：

第 1 步：在 Cobalt Strike 建立监听

在 Cobalt Strike 中先创建一个监听（Listener），记录其 Payload、Host、Port 等字段，后续在 Viper 中需要填写一致的配置信息。

第 2 步：在 Viper 中建立对应的虚拟监听

在 Viper 的监听面板中新建监听，配置与 Cobalt Strike 监听一致的 Host / Port / Payload，并选中"虚拟监听"选项（而不是真实监听）。这里有两个关键点：

• 虚拟监听表示只是新增监听配置信息，并没有实际建立监听；
• 注意：LURI 需要为空。

第 3 步：选择 Session 并运行 Session 克隆模块

回到模块列表，选择Session 克隆模块，目标选择已有的 Windows Session，监听参数选择上一步创建的虚拟监听，然后运行模块。

第 4 步：Cobalt Strike 上线

模块运行成功后，Cobalt Strike 中即出现新的 Beacon 上线，权限迁移完成，后续可以在 Cobalt Strike 侧继续操作该主机。

LURI 为什么必须为空

在 CDN 上线 Meterpreter 教程 和 云函数上线教程 中可以看到，LURI（Listener URI）是 reverse_http(s) 类型监听用于标识回连路径的参数。而在"Session 克隆迁 CS"场景中：

• 回连目标是 Cobalt Strike 的 Teamserver，其监听逻辑并不依赖 Viper 侧配置的 LURI 路径；
• 如果 LURI 非空，克隆出的回连请求会带上该 URI 路径，与 CS 侧监听预期不符，可能导致无法成功上线。

因此官方文档特别强调：建立虚拟监听时 LURI 需要为空。这是该流程中最容易踩坑的参数，务必检查。

自动编排中的死循环风险与防护

Session 克隆会产生新的权限（新的 Session），这一点在与其他功能联动时需要特别注意。根据 自动编排指南：

• Viper 的自动编排功能会在"每当有新的 Session 上线时"自动按顺序执行已配置的模块；
• 如果在自动编排中配置了会生成新权限的模块（比如 Session 克隆），就可能出现死循环：
  • 新的权限 → 触发自动编排模块 → 自动编排模块又生成新的权限 → 再次触发自动编排模块 → ……
• 官方提供的防护手段是"单一主机最大权限数量"参数：配置该参数后，如果系统判断单一主机（同一内网 IP）对应的权限数量大于配置数量，则自动跳过自动编排模块。

因此在自动化场景中使用 Session 克隆时，务必结合该参数设置上限，避免无限克隆耗尽资源、暴露行为。

相关模块对比：Session 克隆 vs 迁移权限到 CobaltStrike

仓库中还存在另一个与 C2 迁移相关的模块 迁移权限到 CobaltStrike，二者定位相近但使用方式不同，可按场景选用：

实战中，如果需要"Viper 与 CS 双平台并存、互为冗余"，优先使用 Session 克隆 + 虚拟监听；如果目标只是把权限交给 CS 管理，两种方式均可达成，可依据团队工作流选择。

使用要点与注意事项

最后汇总使用本模块时需要牢记的要点：

1. Session 类型限制：克隆目标必须是 Windows 类型的 Session（x64 / x86 均可），其他平台 Session 不支持；
2. 监听必须匹配：普通克隆需要有对应的真实监听；迁移 Cobalt Strike 时则改为在 Viper 侧建立虚拟监听；
3. LURI 必须为空：虚拟监听配置中 LURI 务必留空，否则 CS 无法正常接收上线；
4. 警惕自动编排死循环：若将 Session 克隆加入自动编排，务必配置"单一主机最大权限数量"加以限制；
5. 合理使用冗余：克隆出的多个 Session 独立存在，建议在关键节点先克隆备份，再执行高风险操作，避免权限丢失。

本文所述操作均基于 Viper 官方模块文档，相关完整说明可继续阅读 Session 克隆模块文档、监听载荷（虚拟监听）指南、自动编排指南 与 信息收集教程。

• 文档
• 教程
• 网络安全