Cobalt Strike----(9)

SSH 客户端

        Cobalt Strike 使用内置的 SSH 客户端控制 UNIX 目标。该 SSH 客户端接收任务并通过一个父 Beacon路由其输出。  

        使用 ssh [target] [user] [password] 命令从一个 Beacon 中启动 SSH 会话。你也可以使用

ssh-key [target] [user] [/path/to/key.pem] 命令以使用密钥进行身份验证。 这些命令运行 Cobalt Strike 的 SSH 客户端。客户端会向父 Beacon 报告任何连接和身份验证问题。如果连接成功，你将在 Cobalt Strike 的显示中看到一个新会话。这是一个 SSH 会话。右键单击此会话， 然后按 Interact 来打开 SSH 控制台。 输入 help 以查看 SSH 会话支持的命令列表。输入 help 后 跟一个命令名称，以获取有关该命令的详细信息。

运行命令

        shell 命令将运行你提供的命令和参数。运行的命令在 Cobalt Strike 将命令置于后台之前可以锁定 SSH 会话长达 20 秒。 Cobalt Strike 将在可用时报告这些长时间运行的命令的输出。 使用 sudo [password] [command + arguments] 尝试通过 sudo 运行命令。这个别名要求目标的sudo 接受 –S 标志。 cd 命令将更改 SSH 会话的当前工作目录。 pwd 命令报告当前的工作目录。

上传和下载文件

        upload 命令会将文件上传到当前工作目录。 download 命令将下载文件。通过 download 命令下载的文件可以通过 View → Downloads 查看。你也可以输入 downloads 来查看正在进行的文件下载。cancel 命令将取消正在进行的下载任务。

对等 C2

       SSH 会话可以控制 TCP Beacon 。使用 connect 命令启动对一个等待连接的 TCP Beacon 的控制。使用 unlink 断开一个 TCP Beacon 会话的连接。 通过 [session] → Listeners → Pivot Listener… 来设置一个与此 SSH 会话绑定的 pivot 监听 器。这将允许这个失陷的 UNIX 目标可以接收反向 TCP Beacon 会话。此选项的前提是需要 SSH 守护程序的 GatewayPorts 选项的值被设定为 yes 或 ClientSpecified 。

SOCKS Pivoting 和反向端口转发

     使用 socks 命令在团队服务器上创建一个通过 SSH 会话转发流量的 SOCKS 服务器。 rportfwd 命令 还将创建一个反向端口转发，用于路由通过 SSH 会话和你的 Beacon 链的流量。

     rportfwd 有一个警告： rportfwd 命令要求 SSH 守护程序绑定到所有接口（ 0.0.0.0 ）。 SSH 守护程 序很可能会覆盖此设置，并强制端口绑定到 localhost 。你需要将 SSH 守护程序的 GatewayPorts 选项更改为 yes 或 ClientSpecified 。

C2 拓展文件

      许多 Beacon 指标由一个 C2 拓展文件控制。一个 C2 拓展文件由设置和数据转换组成。数据转换是一 个简单的程序，它指定如何转换数据并将其存储在事务中。转换和存储数据的同一程序，向后解释，还 从事务中提取和恢复数据。 要使用自定义配置文件，你必须在启动 Cobalt Strike 团队服务器时在以下位置指定你的配置文件.每个 Cobalt Strike 实例只能加载一个配置文件。

./teamserver [external IP] [password] [/path/to/my.profile]

检查错误

      Cobalt Strike 的 Linux 软件包包含一个 c2lint 程序。 该程序将检查一个通信配置文件的语法，进行 一些额外的检查，甚至使用随机数据对你的配置文件进行单元测试。强烈建议你在将配置文件加载进 Cobalt Strike 之前先使用此工具检查你的配置文件。

./c2lint [/path/to/my.profile]

配置文件语言

创建配置文件的最佳方法是修改现有配置文件。在 Github 上有一些可用的配置文件示例：

https://github.com/rsmudge/Malleable-C2-Profifiles

打开配置文件时，你会看到以下内容:

# this is a comment
set global_option "value";
protocol-transaction {
        set local_option "value";
        client {
    # customize client indicators
            }
server {
    # customize server indicators
}
}

注释以 ＃ 开头，一直到行尾。 set 语句是给一个选项赋值的方法。配置文件使用 { 花括号 } 将语句和信息组合在一起。语句始终以分号结尾。 为了帮助理解，请看这里的配置文件片段：

http-get {
    set uri "/foobar";
    client {
        metadata {
            base64;
            prepend "user=";
            header "Cookie";
}
}

        此部分配置文件定义了 HTTP GET 事务的指标。第一个语句， set uri ，设定客户端和服务器在此事务期间将引用的 URI 。这套语句发生在客户端和服务器代码块之外，因为它适用于它们两者。client （客户端）代码块为执行 HTTP GET 请求的客户端定义指标。在这里客户端指 Cobalt Strike 的 Beacon payload。 当 Cobalt Strike 的 Beacon 回连到团队服务器时，它会发送关于自身的元数据给 Cobalt Strike 。在此 配置文件中，我们必须定义如何编码此元数据和如何使用我们的 HTTP GET 请求发送元数据。 metadata 关键字后跟一组语句，用于指定如何转换和将元数据嵌入我们的 HTTP GET 请求中。在metadata 关键字之后的一组语句称为一个数据转换。

     数据转换中的第一条语句指出，我们将对元数据 base64 编码 [1] 。第二条语句 prepend 接受我们编码的元数据，并将字符串 user= 附加到它前面 [2] 。现在，我们转换后的元数据为

“user=“.base64(metadata) 。第三句话说我们会将转换后的元数据存储到名为 Cookie [3] 的客户端

HTTP 头中。这一部分配置文件就是这个意思。 Beacon 及其服务器都使用配置文件。上面我们已经从 Beacon 客户端的角度解析了配置文件。 Beacon 服务器也会获取相同的信息并向后解释。假设我们的 Cobalt Strike 的 web 服务器收到了获取 URI /foobar 的 GET 请求。现在，它想从事务中提取元数据。

header 语句告诉服务器从哪里来恢复我们转换后的元数据 [1] 。 HTTP服务器会为我们解析来自 HTTP 客户端的请求头。接下来，我们需要处理 prepend （前置）语 句。为了恢复被转换的数据，我们将前置解释为删除前 X 个字符 [2] ，其中 X 是我们添加的原始字符串 的长度。现在，只剩下最后一个语句 base64 需要解释。之前我们使用了 base64 编码函数来转换元数

据。所以现在，我们使用 base64 解码函数来恢复元数据 [3] 。 一旦配置文件解释器完成了所有这些逆语句的操作，我们就会获取原始的元数据。