IT之家 12 月 30 日消息，过去很多人认为 macOS 较为安全，其实原因是 macOS 用户基数较小，黑客兴趣不大，但随着 Mac 市占率持续增长，恶意软件问题亦愈趋严重。Jamf 威胁实验室 12 月 22 日就披露了一种最新的 macOS 恶意软件。

苹果 Mac App Store 之外的应用程序必须经过加密签名和认证，但 Jamf 指出 —— 黑客正在通过地下渠道购买或窃取真实的开发者 ID 证书。这些恶意软件因拥有苹果的“公证证书”，在安装时看起来与合法软件毫无二致，所以能完美躲过苹果安全审查。

此外，恶意代码往往被封装在看似无害的 Swift 执行文件中，在苹果的静态分析中，它们几乎不执行任何操作，完美避开审核。

Jamf 批评苹果的认证流程过于死板，黑客提交审核时提供的是“干净”内容，但一旦程序在用户电脑上运行并连接网络，它才会从云端下载并加载真正的恶意代码。

Jamf 安全研究人员在对内部 YARA 规则命中样本进行分析时，发现了一种与以往不同的 macOS “木马”型恶意软件。

据介绍，该样本在整体行为上与近年来活动频繁的 MacSync Stealer 家族高度相似，但在投递和执行方式上进行了明显调整。研究人员确认，该样本为一款已经完成代码签名并通过 Apple 公证的窃密程序，其执行链条并未遵循此前常见模式。

据介绍，早期的 MacSync Stealer 主要依赖“拖拽到终端”或 ClickFix 风格的社工手段，诱导用户主动在终端中执行脚本；而此次发现的样本则采用了一种更加隐蔽、自动化程度更高的新方式。

该恶意程序被打包为一个经过代码签名并完成公证的 Swift 应用，包含在名为“zk-call-messenger-installer-3.9.2-lts.dmg”的磁盘映像中，并通过 https://zkcall.net/ download 分发。与以往不同的是，该样本不再要求用户进行任何直接的终端操作，而是通过 Swift 构建的辅助可执行文件，从远程服务器获取并执行一个经过编码的脚本。

Jamf 还观察到，另一款名为 Odyssey 的同类程序最新变种也采用了类似的分发方式。值得注意的是，尽管该可执行文件已经完成签名且不需要额外授权步骤，样本中仍然保留了常见的“右键打开”提示。

在对 Mach-O 二进制文件进行分析后，研究人员确认该程序为通用架构构建，并已完成代码签名和公证，其签名关联的开发者团队 ID 为 GNJLS3UYZ4。同时，Jamf 将代码目录哈希值与苹果的吊销列表进行了比对，在分析时并未发现相关证书被吊销。

安全研究人员注意到，该磁盘映像体积异常偏大，达到 25.5MB。分析显示，其体积很可能是由于在应用包中嵌入了用于掩护的诱饵文件所致，其中包括与 LibreOffice 应用相关的 PDF 文档。

在 VirusTotal 平台上，不同样本的检测结果差异较大，有的仅被一个杀毒引擎识别，有的则被多达十三个引擎标记。多数安全引擎将其归类为与 coins 或 ooiid 恶意软件家族相关的通用下载器。在确认该开发者团队 ID 被用于分发恶意载荷后，Jamf 已将相关信息上报 Apple，随后对应证书已被撤销。

在初始检测阶段，Jamf Threat Labs 指出，MacSync Stealer 的大多数载荷通常以内存执行为主，几乎从不在磁盘上留下痕迹。早期版本往往会被 Jamf 的高级威胁防护机制拦截，因为这些版本通常依赖将脚本文件拖入终端执行，或通过 ClickFix 技术诱导用户粘贴一段 base64 编码命令。在这些场景中，载荷会通过 base64 -D 解码、使用 gunzip 解压，存入变量并通过 eval 执行，随后再通过 curl 获取第二阶段载荷。

然而，此次样本的异常之处在于，其触发告警的原因并非上述流程，而是一条用于监控混淆 Bash 脚本执行的威胁防护规则。相关事件显示，一个位于 /tmp/ runner 的 shell 脚本正在运行，这一行为引起了研究人员的警觉。

安全人员进一步检查后发现，该脚本的执行进程来自一个已签名的应用程序，且应用路径显示其直接从已挂载的磁盘映像中运行。对 /tmp/ runner 脚本的分析表明，这正是此前在 MacSync Stealer 攻击活动中出现过的同一脚本，只是在早期版本中通常不会被写入磁盘。解码后的 base64 载荷与常见的 MacSync Stealer 完全一致，使用了此前已出现过的 focusgroovy [.]com 域名，并包含相同的 daemon_function 。

▲ 应用路径详情

Jamf 随后对应用包内的 Swift Mach-O 可执行文件进行了分析。该文件的 _main 函数作为入口点，用于初始化应用状态和日志路径，执行基础的网络连接检查，并在确认网络可用后获取第二阶段载荷。程序解析用户主目录后，会在~/Library/ Logs / UserSyncWorker.log 创建日志文件，并在~/Library/ Application Support / UserSyncWorker/ 目录中维护 last_up 和 gate 等文件，用于记录执行时间和更新状态。相关文件仅在此前不存在时创建。

▲ 混淆后的有效载荷

日志中会记录程序启动信息，并设置约 3600 秒的最小执行间隔，以防止短时间内重复运行。随后，程序调用 checkInternet 进行网络连通性检测，仅在确认联网后才会继续执行 runInstaller 。如果网络不可用，则会记录“preflight: internet=false”，并通过 _exit (1) 正常退出。

▲ 解码后的有效载荷

runInstaller 函数承担了完整的第二阶段载荷下载与执行逻辑。该函数首先读取~/Library/ Application Support / UserSyncWorker / last_up 中保存的时间戳，以实现执行频率限制。如果距离上次执行不足约 3600 秒，程序会记录相关日志并直接退出。在满足条件后，程序再次检测网络状态，并清理 /tmp 目录中此前遗留的文件，例如 /tmp/ runner。

▲ Mach-O 二进制文件中的 _main 函数

随后，程序通过 /bin/ zsh -lc 调用 curl，向一地址发起请求，并使用特定的 User-Agent (macOS)。下载的载荷被写入 /tmp/ runner，请求头信息则保存至 /tmp/ runner.headers。与以往变种相比，该 curl 命令在参数上有所变化，例如将常见的 -fsSL 拆分为 -fL 与 -sS，并新增了 --noproxy 选项。这些变化被认为旨在提升稳定性或规避检测。

▲ HTTP 请求

在执行载荷前，程序会移除 com.apple.quarantine 属性，并将文件权限设置为 750。随后，通过 /usr/ bin / file 检查其 MIME 类型是否为 text/x-shellscript，并验证其输出是否包含预期的脚本描述信息，以确认其为 zsh 脚本。同时，程序还会调用 spctl -a -v 执行 Gatekeeper 检查，确保下载文件能够通过苹果的安全检查。

▲ 用于检索有效载荷的 Curl 命令

载荷执行完成后，/tmp/ runner 文件即被删除，并将当前时间戳写回~/Library/ Application Support / UserSyncWorker / last_update，以继续实施最小执行间隔控制。

Jamf 认为，该 runInstaller 函数构建了一个分层、具备状态感知且具备规避能力的投递流程，通过环境检测、频率限制、网络请求、Gatekeeper 绕过与轻量级校验相结合，并整体封装在原生 Swift 可执行文件中。一旦载荷执行完成，系统中会出现常见的 osascript 对话框，并伴随其他与 MacStealer 活动相关的行为。

Jamf 指出，尽管 MacSync Stealer 本身并非新出现的威胁，但此次案例显示其作者仍在持续演进其投递方式。研究人员此前尚未观察到这种以 Swift 编写、完成代码签名和公证、并能够静默获取和执行第二阶段载荷的投递程序。该变化反映了 macOS 恶意软件生态中的一个更广泛趋势，即攻击者正试图将恶意程序伪装成已签名、公证的合法应用，从而降低早期被发现的风险。