macOS红队实战：用DarwinOps与Mythic C2构建武器化载荷

做红队这几年，我最大的感受是：Windows 上的套路已经卷到天花板，反而是 macOS 靶标经常被人忽略。可现实里，企业里用 Mac 的开发、产品、高管的占比越来越高，BYOD 一普及，macOS 就是一条躲不开的真实攻击面。这篇文章想聊的，是我在实际授权项目里反复打磨的一套组合——用 DarwinOps 来构建包含 Mythic C2 agent 的 macOS 武器化载荷。不是什么理论推演，全是实操里踩出来的经验。

Mythic 是目前开源 C2 里我非常推荐的一个框架，它把 agent、C2 profile 和任务管理全容器化，界面友好，跨平台支持也不错。而 DarwinOps 则负责 macOS 侧的脏活累活：把 agent 打包成可执行的 app bundle、处理签名、做基本的持久化。两者搭配之后，我可以在 15 分钟内从一个全新的服务器环境，跑起来一条可控的 macOS 回连链路。

这篇文章适合三类人看：一类是正在搭 macOS 红队流程的同伴，一类是想了解 C2 载荷落地的安全研究员，还有一类是负责防守的蓝队工程师——了解攻击怎么做，才知道检测该从哪下手。这看着像“攻击教程”，但我默认的前提始终是：所有操作都在授权测试或自建实验环境里进行。这不是免责声明，是红队的基本素养。

1. 整体设计与思路拆解

1.1 为什么 macOS 是红队场景里绕不开的目标

很多红队团队在分配任务时，习惯性把 macOS 归到“非主流”那一类，觉得只要有 Windows 权限就能横向一切。但现实是，过去三四年里企业环境中的 macOS 数量增长得非常快。研发、设计、市场、高管，几乎每个团队都有 Mac 用户。有些公司甚至全员配发 MacBook，Windows 反而成了少数派。

这意味着什么？意味着如果攻击者的初始入口是一封钓鱼邮件，而目标是 Mac 用户，那么载荷必须是 macOS 能跑的格式，C2 通信也要适配 macOS 的网络栈和权限模型。Windows 下的 exe、dll、计划任务，一套全搬不过来。

macOS 和 Windows 在红队视角里最大的差异，我总结为三个层面：

• 签名与公证体系：macOS 的 Gatekeeper 会检查应用是否被 Apple 公证过，未签名或签名异常的应用会被直接拦下。Windows 虽然有 SmartScreen，但很多时候企业环境里并没有强制启用。
• 沙盒与 TCC 权限：macOS 的沙盒和 TCC（透明、同意与控制）权限模型会让载荷在访问摄像头、麦克风、桌面文件、通讯录时弹窗或静默失败。处理不当，载荷会“看起来活着，但实际上什么都干不了”。
• 文件系统与持久化机制：LaunchAgent、LaunchDaemon、登录项、SMAppService，这些机制和 Windows 的注册表、服务完全不同，误用会导致载荷无法随开机启动。

这些问题叠加在一起，就把 macOS 红队变成了一块既麻烦又少人深入研究的领域。麻烦意味着门槛，少人研究意味着机会。对红队来说，这是值得重点投入的方向。

1.2 DarwinOps 与 Mythic C2 的组合逻辑

DarwinOps 这个名字你可能没听过。它不是那种大众视野里的“黑客工具”，更准确地说，它是一套面向 macOS 载荷构建的操作链路。我在团队实践里把它封装成命令行工具，输入是我们的 agent 二进制，输出是一个可以直接分发到目标机器上的 app bundle，中间自动处理包结构、Info.plist 生成、代码签名、属性清理这些杂事。

为什么要单独做这么一层？因为 Mythic 虽然能跨平台生成很多 agent，但 agent 生成完只是裸的 Mach-O 文件，离“能在 Mac 上双击运行”还有很长的路。Mythic 管的是 C2 的控制面，而载荷在 macOS 上能不能活下来，取决于签名、打包、权限这些细节。这两块逻辑如果混在一起，会非常难维护。

所以我把流程拆成两层：Mythic 负责 agent 的生成和通信调度，DarwinOps 负责 macOS 侧的“最后一公里”。这样做的最大好处是解耦，我可以随时换一种 agent 生成方式，或者升级 Mythic 版本，DarwinOps 不需要跟着大改；反过来，如果 Apple 升级了签名策略，我也只需要在 DarwinOps 这一层做适配，而不需要动 C2 架构。

从项目结构上看，DarwinOps 通常分成三条支线：Mach-O 载荷生成、app bundle 打包、签名与公证辅助。每条支线对应一个独立的子命令，方便在自动化流水线里调用。

1.3 为什么选用 Mythic 而不是其他 C2

不是没试过其他方案。Metasploit 的 Meterpreter 在 macOS 上能用，但特征太老，现在很多 EDR 都能精确识别它的内存特征。Cobalt Strike 在红队圈子里是事实标准，但它是商业软件，License 成本高，而且它的跨平台 agent 其实主要还是 Windows 生态，macOS 下可用的功能有限。Sliver 是 Go 写的，跨平台不错，但它的生态和插件机制没有 Mythic 那么丰富。

Mythic 相对它们的优势，我用一个表格直接展示：

实际使用下来，Mythic 最吸引我的是它的“代理 + profile”分离设计。你想用一个自定义的 C2 profile，不用去动 agent 核心代码；你想换 agent 语言，也不用重写控制端逻辑。这种结构对长期维护一套红队基础设施来说，省心太多了。

2. 核心细节解析与实操要点

2.1 DarwinOps 工具链的组成

DarwinOps 在我这边的实践形态，是一组基于 Swift 和 shell 脚本组合出来的工具链。选 Swift 不是因为它在命令行工具里性能多好，而是因为 macOS 的系统 API 对 Swift 的支持最友好，和 Foundation、ServiceManagement 这些框架的交互非常顺滑。

工具链核心分三块：

第一块是“载荷准备”。输入是 Mythic 生成出来的 agent 二进制，DarwinOps 会先做一次基本健康检查：确认架构是 arm64 还是 x86_64，确认它是不是有效的 Mach-O 文件，检查有没有异常的链接库依赖。这一步很容易被忽略。有一次我生成出来一个 agent，本地 file 看是 x86_64，但目标机器是 Apple Silicon，跑起来直接崩。提前做架构检测能省掉大量排错时间。

第二块是“Bundle 打包”。macOS 用户真正习惯双击运行的，是 .app 格式的 bundle，而不是裸二进制。DarwinOps 会自动生成标准的 bundle 目录结构，写好 Info.plist，把 agent 二进制放进 Contents/MacOS 下，并且给一个看起来正常的图标和版本号，让目标用户不会第一眼就起疑。

第三块是“签名与公证”。在真实红队场景里，如果客户要求模拟高级攻击者，通常会提供或者允许使用合法的 Developer ID 证书。DarwinOps 会调用 codesign 对 bundle 做签名，然后调用 notarytool 提交给 Apple 做公证。实验环境下则可以用自签名证书，配合系统策略调整做验证。

这里有一个非常重要的实操注意点：自签名和公证过的签名差别非常大。Gatekeeper 对自签名应用的拦截概率极高，而公证过的应用几乎可以“无感”运行。但在授权红队项目中，是否使用真实证书，一定要提前和客户确认法律边界。别觉得这是小事，边界不清的项目最容易出事。

2.2 Mythic C2 的基础设施需求

要把 Mythic C2 跑起来，硬件需求并不高。官方推荐是 2 核 4G 以上的 Linux 服务器，磁盘 40G 以上。实际我测试过，2 核 2G 的 VPS 也能带动，但启动容器和 Web UI 会明显变慢。如果你打算同时跑多个 agent，或者大量使用截图、文件上传这类功能，内存建议直接给 8G。

操作系统方面，Ubuntu 22.04 或 Debian 12 都是很稳的选择。Mythic 官方对 Docker 的依赖比较重，所有核心服务都跑在容器里，所以部署机器的 Docker 版本要相对新一些，否则可能在启动阶段碰到兼容性问题。

网络侧，你需要一台目标机器能够访问到的服务器。最简单的做法是直接给 Mythic 绑定一个公网 IP，用 HTTPS 暴露 Web 控制台和 C2 回调端口。但暴露端口的同时也意味着你的基础设施容易被蓝队和扫描器探测到。所以我在生产环境里习惯在 Mythic 前面加一层 redirector，用 Nginx 或 Caddy 做流量转发，把真实的服务端 IP 隐藏起来。域名也可以用前置域名，配合 CDN 做流量伪装，让回调流量看起来像普通 HTTPS 请求。

这里需要提醒一句：做基础设施规划时，一定要看清楚当地网络安全相关的法律法规。未授权的扫描和渗透行为是违法的，红队演练必须在客户授权的范围内进行，这一点没有灰色地带。

2.3 前置工作：目标环境分析

我在生成任何载荷之前，都会先搞清楚目标 macOS 环境的几个关键信息：系统版本、芯片架构、是否安装了 MDM 描述文件、TCC 权限的状态。原因很简单，同一个 agent 在 macOS 13 上的行为和 macOS 15 上可能完全不同，尤其是 TCC 和沙盒的收紧力度，每个大版本都在变。

如果目标机器是 Apple Silicon，你还需要额外注意：从 macOS 11 开始，Apple Silicon 的机器会强制要求内核扩展签名，未签名的 kext 或 dylib 很难正常加载。这意味着很多在 Intel 时代好用的注入手法在 M 系列芯片上会失效，红队载荷需要用更“正经”的方式运行，比如直接作为普通用户进程跑起来，而不是强行注入到系统进程。

另一个容易遗漏的点是“目标机器是否开启了 FileVault”。如果开启了 FileVault，而你的持久化机制依赖 LaunchAgent，那么在用户第一次解锁磁盘之前，LaunchAgent 不会被加载。这个延迟有时候会让人误以为载荷失败了，实际上它只是还没到执行时机。

在实验环境里验证这些前置条件，最省事的方法是用虚拟机装一个 macOS。网上常见的虚拟机镜像包、ISO 文件都可以用来搭建实验环境，但要注意版权和合规问题，最好自己从官方渠道制作安装盘。VMware 和 VirtualBox 都能跑 macOS，不过 VMware 对 macOS 的支持更成熟，拖拽文件、共享目录这些功能都更省心。磁盘空间一定要给够，macOS 系统本身加上 Xcode 命令行工具，占用 30G 以上是常事，这也符合很多人遇到过的“macOS 系统数据占用过大”的情况，配置虚拟机磁盘时直接给 60G 以上比较保险。

3. 实操过程与核心环节实现

3.1 部署 Mythic C2 控制端

先说部署环境。我这里用的是 Ubuntu 22.04，Docker 和 Docker Compose 插件都已安装好。Docker 的安装就不展开了，官方仓库的脚本一条命令的事。

Mythic 的部署流程非常标准：

bash复制git clone https://github.com/its-a-feature/Mythic.git
cd Mythic
./mythic-cli start

我第一次跑的时候，以为要等很久，实际上首次启动会拉取多个 Docker 镜像，时间取决于服务器带宽。如果服务器在海外，通常在 5-10 分钟内能完成；如果在国内，建议先配置好 Docker 镜像加速，否则容易超时。

启动完成后，Mythic 会默认监听 7443 端口作为 Web 控制台，回调端口则取决于你选的 C2 profile。默认的配置文件里，数据库、后端 API、前端 UI 都是独立的容器，通过 Docker Compose 统一编排。验证服务状态可以用：

bash复制./mythic-cli status

看到所有服务都是 running 状态后，打开浏览器访问 https://<服务器IP>:7443，用初始化时设置的管理员账号登录。Mythic 的界面是纯 Web 的，操作习惯和普通管理后台差别不大，上手成本很低。

这里有个细节：Mythic 默认会生成自签名证书，首次访问浏览器会提示不安全，这是正常的。如果你在真实红队演练中使用，建议提前替换成正规签发的证书，否则回调流量被中间设备拦下来后，蓝队一眼就能看到证书异常。

3.2 安装代理并配置 C2 Profile

Mythic 本体跑起来只是第一步，接下来要安装你需要的 agent。官方维护的 agent 里，Apollo 是跨平台的，支持 macOS/Linux/Windows，非常适合做 macOS 靶标的默认选择。

安装 agent 的方式有两种：一种是从 GitHub 仓库直接安装，一种是从本地文件安装。最常用的是 GitHub 方式：

bash复制./mythic-cli install github https://github.com/MythicAgents/Apollo

安装完成后，在 Mythic 的 UI 里进入 Payload 管理页面，就能看到 Apollo 这个 agent 了。创建 payload 前，还要配置 C2 profile。我一般选 HTTP profile，然后自定义一个“像正常业务请求”的 URL 路径，比如 /api/v1/telemetry，而不是默认的 /。

这里要重点讲一下心跳间隔和 jitter 的配置。很多新手喜欢把心跳调到 1 秒一次，觉得这样控制更灵敏。但真实网络环境里，这么频繁的请求很容易触发流量分析告警。我在授权项目里通常把心跳设为 60 秒，jitter 设为 20%，这样既保证了控制响应的及时性，又不会让流量形态过于机器化。做红队不是打游戏，低调存活比一切操作都重要。

3.3 用 DarwinOps 生成与打包载荷

Mythic 配置完成后，创建 payload，会直接生成一个 agent 二进制文件。这个文件在 DarwinOps 的流程里叫“原始载荷”。这时候它还只是一个裸的 Mach-O，直接分发到目标机器上，用户看到的是一个黑乎乎的终端窗口，大概率会被当成病毒关掉。

用 DarwinOps 来做打包，核心动作是“生成 app bundle”。我不写死某个固定命令，因为不同版本的 DarwinOps 用法差异很大。但整体过程是固定的，可以在任何环境里复现：

首先，建立标准 bundle 目录：

text复制MyApp.app/
└── Contents/
    ├── Info.plist
    ├── MacOS/
    │   └── myagent
    ├── Resources/
    │   └── icon.icns
    └── _CodeSignature/

然后，编写 Info.plist。关键字段有几个：

• CFBundleIdentifier：尽量做成反向域名格式，比如 com.company.internal-tool，别用 com.hack.payload 这种一眼假的标识。
• CFBundleName 和 CFBundleDisplayName：显示给用户看的名字，要符合目标业务场景。
• LSMinimumSystemVersion：根据目标 macOS 版本配置，如果写得太高，老版本系统会拒绝运行。
• NSHighResolutionCapable：设为 true，避免在 Retina 屏幕上出现模糊。
• LSUIElement：这个字段很重要，设为 true 可以让应用不显示 Dock 图标和菜单栏，实现“无窗口后台运行”。

打完了 bundle 结构，接下来是对整个 app 做签名。签名命令本身不复杂：

bash复制codesign --force --deep --sign "Developer ID Application: Your Name (TEAMID)" MyApp.app

但这里有一个隐藏坑：--deep 参数在部分 macOS 版本上会触发系统对嵌套签名的校验问题。如果你发现目标机器上应用闪退，尝试去掉 --deep，改为对内部可执行文件和动态库先单独签名，再对整体签名。

如果需要过公证，用 notarytool 提交：

bash复制xcrun notarytool submit MyApp.app --keychain-profile "my-notary-profile" --wait

公证平均耗时在几分钟到几十分钟不等，提交后要留意返回的状态。如果收到“Invalid”的反馈，一般是因为 Info.plist 里少了某些字段，最常见的是缺少 CFBundleVersion 和 CFBundleShortVersionString。

3.4 分发与执行验证

载荷打包好之后，分发方式取决于你模拟的攻击场景。如果是钓鱼场景，通常会把 app 压缩成 zip 或 dmg 格式，配合邮件附件或钓鱼网站下发。如果是物理接触场景，可以直接用 U 盘拷贝，这也让很多防御方防不胜防。

为了验证整个链路是否通畅，我会在受控的 macOS 虚拟机里执行这个 app。首次执行时，即使签名正常，Gatekeeper 有时也会因为“应用未从 App Store 下载”而弹窗。在实验环境里，可以通过右键打开，或者临时修改安全策略来绕过。但在真实红队场景中，这种弹窗本身就是失败信号，说明你的签名策略还需要优化。

app 一旦成功运行，Mythic 的控制台上很快就会弹出新的 callback。点进 callback 详情，能看到目标机器的用户名、系统版本、IP 地址、架构信息。这时候说明 C2 链路已经通了。

接下来我会先跑几条基础命令验证 agent 可用性，比如 whoami、system_profiler、sysctl hw.model。这几条命令都是 macOS 上非常正常的系统查询指令，不容易触发告警。确认输出正常后，再逐步进入后渗透阶段，比如开始做权限维持、网络探测、数据收集。

我在这个阶段最看重的不是“能执行多少命令”，而是“agent 在目标系统上的隐蔽性”。所以我每次验证完基本功能，都会在目标机器上跑一下 ps aux 和 lsof -i，确认 agent 的进程名、网络连接状态是否合理。如果进程名一眼看上去就很可疑，比如叫 callback_client，那就说明 DarwinOps 在进程名伪装这块还需要调优。

4. 常见问题与排查技巧实录

4.1 代理进程启动即退出

这是最让人头疼的一大类问题，因为 macOS 的崩溃日志往往不会自动弹给你看。遇到 app 启动后立刻退出，我一般按这个顺序排查：

先看是不是架构不匹配。用 file 看一下 agent 二进制，确认架构。然后在终端手动执行 MyApp.app/Contents/MacOS/myagent，看有没有报错输出。如果报 Killed: 9，基本可以确定是签名问题或者系统策略拦截，而不是代码逻辑错误。

再检查签名是否有效：

bash复制codesign --verify --deep --strict MyApp.app
spctl -a -vv MyApp.app

如果第二行输出 rejected，说明 Gatekeeper 层没有通过。你需要检查证书链、签名时间，或者确认 app 是否在 quarantine 属性下被执行。用手动拷贝到 /Applications 之外目录的方式，通常可以绕过 quarantine 属性的影响，但这也意味着防御方可能留下更明显的痕迹。

4.2 Gatekeeper、TCC 与签名问题

Gatekeeper 拦截是 macOS 红队最常碰到的敌人。很多时候你的 app 在开发机上一路绿灯，一转移到目标机器就被拦，区别就在 quarantine 扩展属性上。curl 或浏览器下载的文件会自动带上 com.apple.quarantine，而通过 U 盘拷贝的文件通常不会。

在授权测试中，如果客户允许，移除 quarantine 属性再执行是常见操作：

bash复制xattr -dr com.apple.quarantine MyApp.app

但请注意，在真实的攻击模拟里，你不可能跑到目标机器上手动执行这条命令。所以正确的思路是：分发链路尽量避免下载类渠道，或者利用合法的签名和公证让 Gatekeeper 直接放行。TCC 的问题则更隐蔽，很多新手在目标机器上调用 screencapture 命令失败，不是因为二进制有问题，而是因为 app 没有被授予“屏幕录制”权限。实验环境下可以手动去系统设置里授权，真实场景则需要 app 的签名身份足够可信，或者利用用户已经在终端 app 上授权过的通道来执行命令。

4.3 回调不稳定、断连

C2 链路中最让人焦虑的不是“连不上”，而是“连上了，但过一会儿就断了”。根据我自己的排查经验，断连问题八成出在网络层，而不是 agent 代码。

先检查服务端端口是不是通的：

bash复制ss -tlnp | grep 443

再看 Mythic 容器的日志：

bash复制./mythic-cli logs

如果是 HTTP profile，重点看访问日志里的请求频率和来源 IP。如果请求正常到达但 payload 执行后无回调，常见原因是 HTTP 心跳的 URL 路径被安全设备拦截了。这时候可以换成更“拟真”的路径，或者改用 SMB profile，利用目标机器之间已有的文件共享通道做通信。

另外，如果目标 macOS 机器是笔记本，经常在不同网络之间切换，DNS 解析延迟也会导致回调断断续续。这种情况下，回调域名尽量用解析速度快的公共 DNS 可访问域名，同时拉长心跳间隔，避免频繁断连在终端上留下一堆失败记录。

4.4 排查速查表

这张表看起来简单，但每一条背后都是真金白银的排错时间。我建议你把这张表印在脑子里，或者贴在自己的红队手册里，遇到问题时先对号入座，而不是去看完整的系统日志浪费时间。

5. 防御视角：这类攻击的检测与缓解

5.1 主机侧痕迹与检测点

红队做到后来，我反而觉得防守方的视角更有意思。站在蓝队角度看，DarwinOps 生成的这类载荷其实并不难发现，只要你盯住几个关键点。

进程维度：macOS 上正常的企业软件不会动不动就有一个名字和你公司无关的进程在后台持续运行。用 ps aux 按 CPU 排序，能发现那些长期驻留、CPU 占用虽然不高但一直没有退出的进程。LaunchAgents 和 LaunchDaemons 目录是永远的神，蓝队应该定期审计 ~/Library/LaunchAgents、/Library/LaunchAgents、/Library/LaunchDaemons 这三个目录下的 plist 文件，看有没有可疑的启动项。

文件系统维度：一个 app bundle 如果自称是业务工具，但只包含一个 1MB 左右的二进制，没有任何资源文件，就很可疑。另外，com.apple.quarantine 属性被移除，或者代码签名时间戳异常，都是值得注意的痕迹。

5.2 网络侧特征与检测点

从网络流量上看，Mythic 默认的 HTTP profile 即使做了伪装，也会有一些可识别的行为模式：例如 agent 与服务器之间以固定时间间隔发起请求，请求体大小接近固定值，响应体经过了加密所以熵值偏高。这些特征在流量分析平台里都是可以建立规则的。

JA3/JA4 TLS 指纹也是一个关键维度。Mythic 容器里内置的 Go 或 Rust HTTP 客户端，TLS 指纹和 Chrome、Safari 有区别。如果企业网关能看到 TLS ClientHello 的指纹，就能拦截大量非浏览器客户端发起的加密流量。这也是为什么高级红队会在 redirector 层面做 TLS 指纹仿真，但对于多数红队基础设施来说，这一步并不容易做到位。

5.3 给企业的几点缓解建议

给正在负责 Mac 终端的运维和安全的读者几句实在话。第一，有条件就上 MDM，把 macOS 设备的 TCC 权限、Gatekeeper 策略、软件黑名单统一管理起来，这比单机手动配置靠谱得多。第二，日志一定要收集。macOS 的 log show 可以拿到很多系统日志，但这些日志如果只在本地，攻击者拿到 root 权限后很容易毁掉。配置集中式日志收集，让主机日志实时上送到 SIEM，才有追溯的价值。第三，EDR 可以上，但要选对 macOS 支持做得好的厂商。不是所有 EDR 的 macOS 端都像 Windows 端那么成熟，选型前一定要做基于真实载荷的绕过评估，而不是只看宣传单。

防守方永远不可能做到绝对安全，但只要你把这些基础工作做好了，那些连签名策略都处理不好、heartbeat 设置得像节拍器一样的红队载荷，就会在你这里碰一鼻子灰。

最后再分享一个小经验。DarwinOps 这套流程跑顺之后，真正影响你效率的往往不是 C2 框架本身，而是那些 macOS 的“系统脾气”。比如虚拟机装 macOS 时磁盘空间给不够，导致系统数据占用过高、后续签名工具装不上；比如测试用虚拟机无法模拟 TCC 弹窗；比如签名公证用的 Apple ID 在 CI 环境里怎么安全地保存凭证。这些都是文档里不会写，但实操里一定会碰到的问题。

我的建议是，正式跑红队项目之前，先在虚拟机环境里完整走三遍上面的流程：第一遍按文档来，第二遍故意制造错误，第三遍尝试自己解决错误。三遍下来，你对 DarwinOps 和 Mythic 的理解会远超“能用”的层面。这套东西后续还可以继续扩展，比如把 DarwinOps 接入自己的自动化编排系统，或者针对 Apple Silicon 重新编译 agent。方向很多，关键是先把基础链路跑扎实。