2026年6月24日XM Cyber团队公开的一项研究直接击穿了macOS企业安全的固有认知。攻击者只需要拿到标准普通用户权限不需要管理员密码、不需要内核漏洞、不需要绕过SIP系统完整性保护就能静默卸载CrowdStrike Falcon传感器永久禁用Kandji等MDM终端管控工具。整个攻击全程在内核信任体系内完成不触发系统安全拦截EDR自身的告警机制也会被提前关闭。这不是某款软件的单个漏洞是把macOS原生机制、行业通用开发缺陷串起来的完整攻击链。本文会从底层原理到完整攻击流程再到可落地的检测加固方案把整个技术细节全部讲透附带可直接复制的检测脚本与安全编码示例。一、先打破认知macOS企业安全的防线到底漏在哪绝大多数企业的macOS安全基线都遵循同一套逻辑开启SIP系统完整性保护、部署CrowdStrike这类企业级EDR、搭配MDM做终端管控。这套组合拳下来很多安全团队默认普通用户权限下做不了高危操作终端的底线能守住。真实情况刚好相反。第三方安全软件为了适配苹果的权限模型普遍采用分层架构恰恰给自己挖了最大的坑。macOS不允许普通应用长期运行在root权限下所有高权限操作安装驱动、修改系统配置、卸载软件都必须拆分到独立的特权助手工具里也就是Privileged Helper Tool。这个工具以root身份后台常驻主程序运行在普通用户权限下双方通过XPC进程间通信框架传递指令。配图1企业级macOS EDR典型XPC分层架构图图示内容左侧为普通用户权限的EDR GUI主进程中间为XPC通信通道Mach消息launchd转发右侧为root权限的Privileged Helper守护进程下方标注各自的权限边界与可执行操作。设计初衷是权限最小化主程序不碰root权限只负责交互Helper只暴露有限的受控接口只做指定的高权限操作。理想状态下Helper只会响应自家主程序发来的指令拒绝所有第三方进程的调用。几乎所有厂商的安全校验都卡在了这一步。绝大多数EDR的Helper服务只验证调用方的代码签名证书只要证书和自家开发者证书一致就默认是合法调用方完全不校验进程运行时的完整性也不校验调用上下文。这个设计缺陷加上macOS内核的签名信任缓存机制刚好凑成了完整的提权通路。不需要攻破系统防线只需要借合法进程的“身份”发一条XPC消息root权限的Helper就会乖乖执行卸载指令。二、攻击的核心基石被所有人忽略的内核签名缓存机制很多人对macOS代码签名有个误解觉得系统会实时校验每个进程的签名状态只要进程被篡改立刻就会被系统拦截。实际运行逻辑完全不是这样。代码签名完整校验的计算成本很高如果每次进程通信、每次系统调用都重新做全量校验系统性能会出现肉眼可见的下降。苹果为了兼顾安全与性能在内核层做了信任缓存机制二进制文件第一次启动时内核会完成完整的签名校验把校验结果代码目录哈希、信任状态缓存下来短时间内重复访问直接复用缓存结果不会重复执行完整校验流程。这个缓存由内核AMFIApple Mobile File Integrity模块维护普通用户无法直接读取或修改缓存会保留数分钟到数十分钟具体时长由系统根据内存压力动态调整。缓存生效期间哪怕进程内存被注入、资源文件被篡改内核返回的签名校验结果依然是初始的合法状态。XM Cyber的攻击链最核心的突破点就在这里先启动一次合法签名的EDR主程序让内核生成信任缓存在缓存失效前通过修改应用资源文件向进程注入恶意代码用被篡改的进程向root级Helper发XPC请求Helper向内核查询调用方签名拿到的是缓存中的合法结果直接放行请求。整个过程没有突破任何系统安全机制完全是在苹果设计的规则内完成。苹果官方文档里明确写了信任缓存的存在但几乎没有安全厂商把这个特性纳入XPC鉴权的防御逻辑所有人都默认内核返回的签名结果等于进程当前的真实状态。三、完整攻击链拆解从普通用户到静默卸载EDR的四步走整个攻击链分为四个连贯步骤所有操作都在普通用户权限下完成不需要弹窗确认不会触发系统告警。熟练操作的话全程耗时不超过30秒。第一步选定可信注入载体攻击者不会随便找个普通应用当注入载体目标非常明确直接选EDR自身的主程序。EDR主程序本身就具备和自家Helper通信的权限开发者证书完全匹配是Helper默认信任的调用方。用它当载体不需要伪造签名不需要跨进程欺骗只需要劫持它的执行流就能直接调用特权接口。普通用户具备修改应用包的权限是攻击成立的前提。绝大多数企业部署EDR时都会把安装包放到/Applications目录下。如果管理员没有手动收紧目录权限普通用户默认拥有应用包内资源文件的修改权限——不需要管理员密码直接就能改。第二步NIB资源注入劫持进程篡改可执行文件会破坏代码签名立刻被系统检测到但修改资源文件不会。NIB是macOS应用的Interface Builder界面资源文件存储了UI控件、类绑定、事件响应关系属于应用包内的资源文件不在主二进制的签名校验范围内。绝大多数安全软件的完整性校验只覆盖Mach-O可执行文件不会逐文件校验所有资源。攻击者只需要修改EDR主程序包内的NIB文件插入一个自定义的NSObject子类在类初始化方法中写入恶意载荷。下次启动主程序时加载NIB文件会自动执行插入的代码完成进程内注入。整个过程不修改主二进制文件层面的签名校验完全可以通过内核生成的信任缓存依然是合法状态。这种注入方式比DYLD注入更隐蔽大部分EDR的内存注入检测规则都不会覆盖NIB加载场景。第三步复用内核信任缓存绕过XPC鉴权注入完成后恶意代码运行在EDR主程序的进程空间内和正常业务代码共享同一个进程身份。接下来就是建立XPC连接。macOS的XPC服务通过Mach端口注册所有root级Helper的服务名都是全局可见的任何进程都可以尝试发起连接。连接建立后Helper会执行身份校验拿到调用方的PID调用系统接口查询进程的代码签名信息和预设的厂商证书做比对。这一步的校验逻辑存在本质缺陷。Helper调用的SecCodeCopySigningInformation接口返回的是内核缓存的签名结果不会实时扫描进程内存做完整性校验。被注入的进程内核缓存里的证书信息完全合法Helper会直接判定为可信调用方放开所有接口的调用权限。第四步调用私有XPC接口执行卸载通过身份校验后剩下的就是调用Helper暴露的私有接口。CrowdStrike Falcon的Helper内置了完整的卸载逻辑对应私有方法uninstallSensor。正常流程里只有用户在主界面点击卸载、输入管理员密码后主程序才会调用这个方法。但XPC接口本身没有做二次权限校验只要调用方身份可信直接传参就能执行。root权限的Helper执行卸载流程时会依次停止Endpoint Security内核扩展、移除LaunchDaemon持久化项、删除内核过滤规则、清理所有本地文件。全程没有弹窗不需要用户交互普通用户上下文就能静默完成。卸载完成后EDR进程完全消失企业管控后台只会显示终端离线不会产生任何攻击告警——因为所有操作都是EDR自身组件执行的合法流程。配图2无内核漏洞XPC提权攻击完整流程图图示内容按执行顺序标注四个阶段1. 启动合法EDR主程序→内核生成签名信任缓存2. 修改NIB资源注入恶意载荷3. 劫持进程建立XPC连接→复用缓存通过身份校验4. 调用私有卸载接口→root权限执行EDR移除。四、两款主流企业工具的利用实测细节这套攻击逻辑不是针对某一款产品的特例是行业普遍存在的设计缺陷。XM Cyber团队实测了三款主流企业安全产品其中两款已经公开分别是CrowdStrike Falcon和Kandji MDM第三家厂商仍在修复中暂未披露名称。CrowdStrike Falcon 完整卸载CrowdStrike是全球市场份额最高的macOS EDR产品也是这次攻击中最受关注的目标。攻击达成的最终效果是完全移除传感器不是简单终止进程。Falcon自带进程自监控机制常规kill命令杀掉进程后会立刻自动重启内核扩展也会持续拦截恶意操作。但通过XPC调用官方卸载接口会直接触发完整的自清理流程所有防护组件一次性全部移除没有残留。整个卸载过程不会触发Falcon自身的行为检测规则。在EDR的视角里这是主程序发起的合法卸载操作属于正常业务流程不会产生任何高危告警。漏洞披露后CrowdStrike响应速度很快已经在所有受支持的macOS传感器版本中推送了补丁新增了运行时进程完整性校验同时给卸载接口增加了强制管理员密码验证并且向研究团队支付了安全赏金。Kandji MDM 永久禁用CVE-2026-39118Kandji是主流的苹果设备MDM管理平台漏洞编号CVE-2026-39118影响4.7.5(5374)之前的Agent版本。MDM的权限比普通EDR更高能管控设备的所有系统策略所以攻击流程也更复杂分为两个阶段。第一阶段先通过XPC调用关闭MDM内置的卸载保护锁解除防篡改机制第二阶段调用终端安全接口终止Endpoint Security框架扩展清空设备上的所有合规策略。攻击完成后设备会从MDM管理后台解绑企业无法再远程下发策略、锁定设备、擦除数据也看不到终端的任何安全状态。相当于直接把企业管控的设备变成了普通个人设备所有安全约束全部失效。Kandji已经在4.7.5版本中修复了这个漏洞给所有高风险XPC接口增加了会话授权令牌校验不再仅凭签名信任就放行操作。五、攻击能成立的四个底层原语这套攻击链没有用到任何零日漏洞四个核心组件全是已知的系统特性和通用开发缺陷之前都是单独出现没有人把它们串成完整的提权链路。代码签名缓存的信任复用这是系统层面的性能优化不是安全漏洞。苹果的设计逻辑里信任缓存只用来提升启动速度没有考虑到会被用来绕过运行时鉴权。目前所有macOS版本都保留这个机制苹果也没有把它定义为安全问题自然不会单独修复。这个特性决定了只要进程启动时签名合法运行中被篡改后短时间内所有系统接口返回的签名状态都是合法的。所有依赖系统签名接口做鉴权的服务都会受到影响。XPC客户端鉴权的普遍缺失这是厂商侧的核心问题属于典型的CWE-284不当访问控制。绝大多数开发者写XPC服务时身份校验只做一步比对调用方的证书颁发者。只要证书是自家的就默认可信完全不校验调用方的二进制路径、运行时状态、调用参数范围。更严谨一点的厂商会校验进程的Bundle ID但Bundle ID可以随便伪造只要证书一致就能通过起不到实际防御作用。几乎没有厂商会在XPC服务端做运行时内存完整性校验。NIB资源注入的低门槛高隐蔽性NIB/XIB注入不是新技术已经存在很多年但一直被当成小众技巧没有被大规模利用。相比DYLD注入、Mach-O注入NIB注入的优势非常明显不修改可执行文件不破坏代码签名不需要绕过库验证Library Validation绝大多数安全软件的完整性检测都不会覆盖资源文件。普通开发者甚至不需要懂逆向用Xcode打开NIB文件拖一个控件、绑定一个自定义类就能完成注入门槛极低隐蔽性极高。用户域应用目录的可写权限这是企业部署的常见疏漏。很多管理员以为把软件装到/Applications目录就安全了实际上默认配置下普通用户对很多应用包具备写权限。SIP系统完整性保护只覆盖/System、/usr这类系统目录第三方应用所在的/Applications不在保护范围内。如果管理员没有手动通过chmod修改权限普通用户可以随意修改应用内的资源文件甚至替换部分二进制组件。如果应用部署时设置为仅管理员可写NIB注入的入口就会被直接堵死攻击链第一步就无法执行。六、企业场景下的真实风险有多大很多人会觉得攻击前提是已经拿到普通用户权限属于内网渗透的后渗透阶段风险没那么大。实际企业场景里这套攻击链的破坏力比普通内核提权还强。内网横向渗透门槛大幅降低传统内网渗透拿到普通员工账号后想进一步操作需要先提权到管理员再想办法绕过EDR。现在不需要这么麻烦拿到普通账号就能直接卸载EDR关掉终端监控。EDR一旦下线攻击者就可以自由部署后门、窃取本地凭证、扫描内网横向移动全程没有行为审计没有告警触发。相当于终端的最后一道防线直接消失攻击者可以在完全隐身的状态下操作。无告警静默逃逸运营侧极难发现普通攻击哪怕成功提权多多少少会留下异常行为日志EDR可能会触发告警。这次攻击完全不同所有操作都由EDR自身的合法组件执行走的是官方卸载流程EDR自身的检测规则不会把它判定为攻击。卸载完成后EDR进程直接退出不会向后台发送告警信息。企业安全运营团队只能看到终端离线无法区分是用户主动卸载、网络故障还是攻击导致。如果终端数量多离线告警很容易被淹没攻击可能几天甚至几周都不会被发现。SIP完全不产生拦截效果绝大多数企业把SIP当成macOS安全的底线觉得只要SIP开启内核层面就是安全的。但这次攻击全程不触碰系统目录不修改系统文件不加载恶意内核扩展所有操作都在第三方软件的权限范围内。SIP的保护边界是系统自身管不了第三方软件自己的XPC服务缺陷。哪怕SIP开到最高级别只要第三方软件的Helper鉴权有问题攻击就能成立。无内核操作痕迹取证难度极高内核漏洞利用、恶意kext加载都会在内核日志里留下痕迹事后取证很容易定位。这套攻击全程在用户态完成所有系统调用都是合法的读取文件、加载NIB、建立XPC连接、发送消息每一步都是正常操作。事后取证只能查到应用资源文件被修改过很难追溯到具体的攻击操作更无法还原完整的攻击链路。如果攻击者卸载完EDR再清理日志几乎不会留下可追溯的证据。七、可直接落地的检测脚本与加固方案应对这类攻击不需要等苹果更新系统企业侧有很多可以立刻落地的检测和加固措施下面提供完整可复制的脚本和配置方案。1. 系统特权XPC服务枚举脚本这个脚本可以列出所有root级LaunchDaemon注册的Mach XPC服务帮助安全团队排查终端上暴露了哪些高权限XPC接口评估攻击面。#!/bin/bash# 枚举所有root级LaunchDaemon的XPC Mach服务echo 系统root级XPC Mach服务列表 launchctl print system|grep-A20mach services|grep-E^\s[a-zA-Z0-9\.\-]|whileread-rservice;do# 提取服务名svc_name$(echo$service|awk{print $1})# 查找对应的launchd plistplist_path$(grep-rl$svc_name/Library/LaunchDaemons/2/dev/null|head-1)if[-n$plist_path];thenecho服务名:$svc_nameecho对应配置:$plist_pathecho---fidoneechoecho 常见安全软件XPC服务检查 # 检测CrowdStrike Falcon XPC服务iflaunchctl print system|grep-qcom.crowdstrike;thenecho[存在] CrowdStrike Falcon 特权XPC服务elseecho[未安装] CrowdStrike Falconfi# 检测Kandji Agent XPC服务iflaunchctl print system|grep-qio.kandji;thenecho[存在] Kandji MDM 特权XPC服务elseecho[未安装] Kandji MDMfi2. 应用目录权限检测脚本这个脚本用来检测安全软件的应用包是否允许普通用户修改排查注入入口风险。#!/bin/bash# 检测关键安全软件的目录权限check_app_writable(){app_path$1app_name$2if[-d$app_path];then# 检查当前用户是否有写权限if[-w$app_path/Contents];thenecho[风险]$app_name资源目录当前用户可写存在NIB注入风险echo 路径:$app_pathls-ld$app_path/Contentselseecho[安全]$app_name资源目录不可写fielseecho[未安装]$app_namefi}echo 安全软件应用包权限检测 check_app_writable/Applications/Falcon.appCrowdStrike Falconcheck_app_writable/Applications/Kandji.appKandji Agentechoecho 加固建议 echo执行以下命令锁定应用目录权限需管理员权限echosudo chown -R root:admin /Applications/Falcon.appechosudo chmod -R 755 /Applications/Falcon.app3. 企业侧即时加固措施强制升级客户端版本第一时间把CrowdStrike Falcon、Kandji Agent升级到最新修复版本这是最直接有效的修复方式旧版本完全暴露在风险中。收紧应用目录权限所有企业部署的安全软件、管理工具统一设置为root所有、admin组可读可执行普通用户仅只读权限直接封堵NIB注入入口。MDM下发强制配置通过MDM配置文件限制普通用户修改/Applications目录下的企业应用开启系统扩展强制启用禁止用户手动停用Endpoint Security扩展。新增行为检测规则在EDR中添加NIB修改、非主程序调用特权XPC服务的检测规则针对异常XPC通信产生告警。配图3XPC服务鉴权修复前后对比示意图左侧为旧版鉴权逻辑仅校验调用方证书→匹配即放行右侧为新版鉴权逻辑证书校验路径校验运行时哈希校验高危接口二次授权→全部通过才放行。八、开发侧避坑指南安全XPC服务的编码规范这次暴露的问题是整个行业的共性缺陷所有开发macOS特权XPC服务的团队都需要重新审视鉴权逻辑。下面给出标准的安全鉴权方案包含可直接复用的代码示例。错误的鉴权方式绝大多数厂商的现状只校验调用方的签名证书只要证书匹配就放行完全不考虑进程是否被篡改。这种校验方式在信任缓存机制面前形同虚设。正确的多层鉴权逻辑安全的XPC服务端必须至少做四层校验缺一不可签名证书校验验证调用方的代码签名证书是自家颁发的这是基础门槛二进制路径校验验证调用方的可执行文件路径必须是指定安装目录下的官方主程序防止任意同签名程序调用运行时状态校验检查调用方进程是否存在注入痕迹比如异常动态库、环境变量注入高危接口二次授权卸载、停止防护、修改系统配置这类高危操作必须弹出管理员密码验证不能静默执行。安全鉴权示例代码Objective-C// XPC服务端身份校验完整实现-(BOOL)verifyClientIdentity:(xpc_connection_t)connection{// 1. 获取调用方PIDpid_t clientPidxpc_connection_get_pid(connection);// 2. 获取调用方代码签名对象SecCodeRef clientCodeNULL;OSStatus statusSecCodeCreateWithPID(clientPid,kSecCSDefaultFlags,clientCode);if(status!errSecSuccess||clientCodeNULL){returnNO;}// 3. 校验签名证书链NSDictionary*signingInfo(__bridge_transfer NSDictionary*)SecCodeCopySigningInformation(clientCode,kSecCSDynamicInformation);if(!signingInfo){CFRelease(clientCode);returnNO;}// 校验证书颁发者是否为公司开发者证书SecCertificateRef leafCert(__bridge SecCertificateRef)[signingInfo objectForKey:(__bridge NSString*)kSecCodeInfoCertificates][0];if(![selfverifyCertificateIsOur:leafCert]){CFRelease(clientCode);returnNO;}// 4. 校验调用方二进制路径NSString*clientPath[signingInfo objectForKey:(__bridge NSString*)kSecCodeInfoPath];if(![clientPath isEqualToString:/Applications/Falcon.app/Contents/MacOS/Falcon]){CFRelease(clientCode);returnNO;}// 5. 校验运行时完整性检查是否存在DYLD注入charenvBuf[4096];intretproc_pidinfo(clientPid,PROC_PIDTASKALLINFO,0,envBuf,sizeof(envBuf));if(ret0){// 检查异常环境变量与动态库if([selfcheckProcessInjection:clientPid]){CFRelease(clientCode);returnNO;}}CFRelease(clientCode);returnYES;}// 高危接口额外校验强制管理员授权-(BOOL)verifyAdminAuthorization{AuthorizationRef authRefNULL;OSStatus statusAuthorizationCreate(NULL,kAuthorizationEmptyEnvironment,kAuthorizationFlagInteractionAllowed|kAuthorizationFlagExtendRights,authRef);if(status!errAuthorizationSuccess){returnNO;}AuthorizationItem rightItem{kAuthorizationRightExecute,0,NULL,0};AuthorizationRights rights{1,rightItem};statusAuthorizationCopyRights(authRef,rights,kAuthorizationEmptyEnvironment,kAuthorizationFlagInteractionAllowed|kAuthorizationFlagExtendRights,NULL);AuthorizationFree(authRef,kAuthorizationFlagDefaults);returnstatuserrAuthorizationSuccess;}除了多层鉴权还可以增加一次性会话令牌机制主程序每次调用高危接口前先向Helper申请随机令牌令牌有效期限制在几秒内调用时必须携带有效令牌。这样可以有效防止重放攻击和内存劫持后的延迟调用。九、XPC Hunter与未来macOS攻防趋势XM Cyber团队的研究员Hillel Pinto会在2026年8月的Black Hat USA Arsenal环节开源名为XPC Hunter的扫描工具。这个工具可以自动枚举系统内所有XPC服务检测鉴权缺陷识别可利用的提权点。工具开源后XPC提权的门槛会进一步降低攻击者可以直接用它批量扫描企业终端定位未打补丁的安全软件。可以预见未来一两年内XPC服务缺陷会成为macOS终端攻击的主流方向。从攻防对抗的趋势来看接下来会出现三个明显的变化第一攻击重心从内核转向用户态IPC。macOS的内核防护越来越强漏洞利用成本极高而且需要绕过SIP。XPC服务的缺陷普遍存在利用难度低不需要系统级漏洞性价比远高于内核攻击。后续会有越来越多的研究团队挖掘各类第三方软件的XPC漏洞。第二厂商会快速补全鉴权逻辑但仍会有大量长尾设备。头部安全厂商已经开始修复但很多小众EDR、企业管理工具、驱动类软件还没有意识到这个问题。大量企业终端不会及时更新客户端漏洞会长期存在。第三苹果可能会在系统层面强化XPC安全。目前苹果还没有针对这个问题发布官方公告但长期来看苹果大概率会在后续macOS版本中给XPC增加更严格的默认鉴权机制比如强制要求服务端校验调用方的entitlement或者增加系统级的XPC权限管控。十、写在最后这次攻击最值得反思的地方在于它没有用到任何高深的漏洞利用技术只是把几个被忽略的系统特性和开发缺陷串在了一起就击穿了全球顶级EDR的防护。企业安全团队很容易陷入一个误区把注意力放在内核漏洞、零日攻击这类高大上的威胁上却忽略了最基础的权限配置、接口鉴权这类问题。真正造成破坏的攻击往往都是从最基础的设计缺陷切入。macOS的企业安全防护不能只依赖SIP和EDR需要从权限配置、接口审计、行为检测多个维度同时发力。定期排查终端上的特权XPC服务收紧应用目录权限及时更新安全软件版本这些基础工作做好了就能挡住绝大多数攻击。互动讨论你所在的企业用的是哪款macOS EDR有没有做过XPC层面的安全检测你觉得苹果会在下一代macOS系统里对XPC通信机制做哪些安全层面的收紧