# 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]。 一旦配置文件解释器完成了所有这些逆语句的操作,我们就会获取原始的元数据。