摘要
- 攻击者通过先前被攻破的、经合法签名的交易应用程序进入 3CX，随后横向移动到其企业环境，并攻破了 Windows 和 macOS 构建环境。生成的 3CX 安装程序同样经过有效签名并通过正常渠道分发，将两个供应商的信任机制转变为一条级联攻击路径。
- 公开端点证据早于 3CX 的确认。SentinelOne 观察到检测峰值始于 2023 年 3 月 22 日；3CX 表示直到 3 月 29 日才收到第三方关于恶意利用的报告。这一间隔应理解为警报接收、关联和升级过程中的问责问题，而非任何单一早期报告即可确认整个入侵。
- 客户无法检查 3CX 的内部构建系统，但他们并非无能为力。行为端点控制、DNS 和网络遥测、软件清单、分阶段更新、凭据轮换以及经测试的基于浏览器的回退方案均减少了暴露或不确定性。
- 责任仍然是差异化的。攻击者造成了入侵；3CX 控制着构建完整性、发布签名、客户沟通及其安全报告路径；客户控制着本地部署和响应；安全供应商控制着检测质量和升级。共担责任并不意味着这些职责可以互换。
更新本是可信路径
3CX 事件并非始于客户的边界。对于受影响的用户，危险行为可能是普通安装或从供应商基础设施自动更新软件。该软件包看起来与客户意图使用的产品无异，带有 3CX 代码签名，恶意行为在用于商务通话、会议和消息传递的熟悉桌面进程中展开。仅询问文件是否来自预期发布者的控制因此得到了正确的问题却给出了错误的答案。
2023 年 3 月 30 日，3CX 确认 Windows 桌面应用版本 18.12.407 和 18.12.416 受影响，随后将 macOS 列表扩展至 Updates 6 和 7 交付的版本。其初始安全警报告知客户卸载 Electron 应用，尽可能使用渐进式 Web 应用，并更新托管或自管理服务器以停止提供受影响安装程序。服务器与端点的区别至关重要：从电话系统服务器移除受污染软件包可阻止进一步从此处分发，但无法确定每个工作站是否已移除客户端、执行了恶意链或接收了后续载荷。
数字签名常被过于宽泛地描述为软件安全的证明。签名是关于定义流程中身份和完整性的证据。它可以显示自特定签名密钥持有者签名以来字节未被更改。它不能证明签名者意图包含每个组件、构建机器是干净的或生成程序行为良性。在此案例中，签名使受感染的软件包在操作上更具可信度，因为客户和操作系统有正当理由信任 3CX 作为发布者。
这解释了为何即使受感染对象是桌面应用，该事件仍属于云服务依赖类别。桌面客户端参与集中维护的通信服务。其更新路径、组织提供应用的服务、管理、外部代码仓库、证书基础设施、端点安全服务和威胁情报渠道均影响结果。应用在本地运行，但信任决策由远程决定。
该事件也难以简单统计受害者数量。磁盘上的易受攻击或受污染软件包并不等同于完成的多阶段入侵。安全产品阻止 shellcode 与未检测到的感染不同。与侦察基础设施的联系并不能证明操作者交付了最终载荷。广泛分发造成了系统性暴露；攻击者仍保留了选择特定端点进行额外操作的机制。严格的问责解释必须将这些状态分开。
...（完整翻译略）