安全产品致盲

“安全产品致盲”不是单指结束杀毒进程，而是攻击者让防护体系看不见、报不出、传不上去或无法处置的一组动作。目标可能是 AV、EDR、日志、云端信誉、更新服务、网络传感器，也可能是它们之间的通信链路。

先说结论：

关闭进程只是最显眼的一种
更隐蔽的致盲会保留进程外观
却让采集、检测、上报、更新或响应能力失效

因此，“安全软件进程还在”不等于安全产品健康。

能力链

可以把终端安全产品抽象成五个连续环节：

传感器采集
↓
本地分析与策略执行
↓
事件缓存和日志记录
↓
网络上报与云端判定
↓
响应、隔离与恢复

攻击者只需破坏其中一个关键环节，就可能制造检测缺口。例如驱动仍在但用户态服务无法读取事件；服务仍在但证书、代理或防火墙规则阻断上报；控制台仍显示设备在线，但策略和病毒库长期无法更新。

常见手法

停止或终止组件

最直接的方式是终止进程、停止服务、禁用驱动或改变启动类型。优点是见效快，缺点是痕迹明显，容易触发自保护和看门狗。

高价值检测点包括：

• 非产品自身进程打开安全进程的终止权限。
• 服务停止、启动类型变化与提权事件紧邻。
• 安全进程反复退出和重启。
• 驱动卸载、设备对象消失或系统重启后组件未恢复。

篡改配置与策略

攻击者可能关闭实时防护、排除特定路径或进程、降低日志级别、禁用防篡改、改变扫描范围，或者利用应用控制和软件限制策略反向禁止安全组件启动。

这种方式比直接杀进程更隐蔽，因为系统可能认为它只是在执行一项“管理员策略”。判断关键是：谁改的、从哪里改的、是否经过受管控制面，以及策略目标是否集中指向安全工具。

反用 SRP 禁止安全组件启动

SRP（Software Restriction Policies，软件限制策略）本来用于企业管控软件运行，但高权限攻击者也可能反向利用它，把安全产品组件加入禁止运行规则。需要重点关注的策略位置是：

HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers

可以把相关结构抽象理解为：

CodeIdentifiers
├── DefaultLevel
├── PolicyScope
├── TransparentEnabled
├── 0\Paths\{Rule-GUID}
│   ├── ItemData
│   ├── SaferFlags
│   ├── Description
│   └── LastModified
└── 262144\Paths\{Rule-GUID}

其中 0 通常表示 Disallowed 规则级别，262144 是十进制的 0x40000，对应 Unrestricted。ItemData 记录被规则命中的文件或目录路径，常见目标可能是安全软件 EXE、服务程序、更新器或安装目录。

研判时不能只看单独一个 SaferFlags 就判断规则语义，应结合父级安全级别、规则类型、ItemData、DefaultLevel 和策略来源一起看。还要注意，.sys 路径出现在 SRP 规则里，并不等于所有 Windows 版本、所有启动阶段都会阻止驱动加载；最终效果还会受到服务配置、代码完整性、WDAC、HVCI 和启动时序影响。

这类致盲链路可以抽象为：

获得管理员或 SYSTEM 权限
↓
枚举安全产品目录和关键组件
↓
在 0\Paths\{GUID} 下创建限制规则
↓
ItemData 指向安全软件 EXE、更新器、服务程序或目录
↓
策略刷新，或等待服务 / 主机重启
↓
安全组件后续启动时被系统策略拒绝

几个边界要一起记住：修改 HKLM 下策略通常需要高权限；已经运行的组件不一定立即退出，效果可能在服务重启、产品升级或主机重启后才暴露；域 GPO、MDM 或配置管理平台可能覆盖本地篡改；目录级规则影响范围大，但也更容易受到安装路径、升级路径和重解析点影响；安全产品防篡改、WDAC 和应用控制策略会改变最终结果。

检测时可以重点关联：

非受管进程写入 Safer\CodeIdentifiers
+
新增或修改 0\Paths\{GUID}\ItemData
+
目标命中安全产品路径
+
策略刷新、服务重启或安全组件启动失败

建议采集修改进程、用户、完整性级别、父进程和来源；记录新旧注册表值、规则 GUID、父级安全级别和规范化后的 ItemData 路径；统计短时间创建的规则数量和涉及的安全厂商数量；再关联后续策略刷新、服务重启、启动失败、更新停止和中心心跳下降。还应比较本地策略与域 GPO、MDM、配置管理平台之间是否出现漂移。

正常管理员也可能通过 GPO 或 MDM 限制软件运行，收敛误报时应先核对策略来源、操作者、维护窗口和审批工单；再判断 ItemData 是否集中命中 EDR、AV、日志代理、更新器或恢复工具；关注短时间创建多个随机 GUID、覆盖多家安全产品的批量特征；最后结合安全服务启动失败、策略或特征停止更新、中心心跳中断来确认影响。即使写入者是微软签名白进程，只要本地策略偏离受管基线，也不能直接放行。

阻断更新、信誉与遥测

通过防火墙、代理、DNS、hosts、路由或证书配置阻断安全产品访问云端，可以让它无法更新特征、查询信誉、上传事件或接收响应命令。

此时终端上的 UI 可能仍然正常，但会出现：

• 病毒库、引擎或策略版本长期落后。
• 控制台心跳间歇或只有部分通道在线。
• 本地事件存在，中心平台缺失。
• 对更新和信誉域名的解析或 TLS 连接持续失败。

破坏文件、注册信息与依赖

删除、替换、重命名组件，修改 ACL 或所有者，破坏注册表和 WMI 状态，都可能让产品无法启动或升级。攻击者也可能只破坏某个关键依赖，使故障看起来像普通软件损坏。

对已签名组件的修改通常会破坏签名；但攻击者可以替换配置、侧加载依赖或改变加载路径，因此需要同时校验文件完整性和模块加载。

干预用户态监控

部分攻击会在进程内取消 Hook、绕过用户态拦截、直接使用更底层接口，或让恶意代码运行在传感器覆盖不足的宿主中。此类动作不一定“关闭 EDR”，而是让特定行为绕过采集。

如果同一事件在内核遥测、ETW、系统日志和产品日志之间出现矛盾，应考虑采集路径被绕过或受损，而不是简单认为“行为没有发生”。

滥用高权限驱动

合法签名但存在已知漏洞的驱动可能被用来获得内核读写能力，随后针对安全进程、回调、驱动和受保护进程实施更强干预。常见概念是 BYOVD。

这类风险的关键不只是“加载了一个签名驱动”，而是：

• 驱动是否在已知易受攻击驱动清单中。
• 谁在什么路径释放并加载它。
• 加载后安全组件是否立即异常。
• 系统是否启用了易受攻击驱动阻止规则和 HVCI。

日志与审计致盲

攻击者可能停止日志服务、修改审计策略、清除特定日志、缩短保留、破坏转发或制造大量噪声。成熟攻击更可能只削弱与后续动作相关的日志，而不是清空所有内容。

判断时应比较本地日志、中心转发、网络侧记录和身份平台事件。单点日志缺失可能是故障，多源数据在同一时刻共同断层才更有说服力。

规避扫描而不关闭产品

排除项、受信任路径、合法签名宿主、白加黑、内存执行和安装扩展都可能让安全产品保持运行，却不再检查关键载荷。这属于信任链滥用，和直接停用工具一样应归入防御削弱。

DLL 增肥与扫描容量限制

“DLL 增肥”通常指给磁盘上的 DLL 增加与主要功能无关的数据，使它的体积异常增大。它属于 MITRE ATT&CK T1027.001 Binary Padding 描述的二进制填充。额外数据可能体现在尾部附加区、节区或资源中；文件变大本身不会自动改变 DLL 的加载关系，也不会让其中的代码自动执行。

攻击者希望利用某些安全产品、云端提交或沙箱的文件大小上限、扫描深度或分析耗时限制，让大文件被跳过、只做部分分析，或无法上传。这只会影响具备相应限制的扫描路径；不能从“DLL 很大”推断“所有杀软都不扫描”或“EDR 已被关闭”。即使静态分析受限，文件创建、模块加载、内存行为和后续通信仍可能被观察。

在白加黑利用中，合法签名的 EXE 可能照常加载同目录的黑 DLL，增肥针对的是黑 DLL 的扫描与分析成本，不是把白 EXE 的签名传递给它。若被修改的 DLL 原本有签名，还须重新核对签名有效性；“白文件签名有效”不能替黑 DLL 背书。

研判时先确认安全产品对该文件的实际处理状态：已完整扫描、达到限制而未扫描、扫描超时、仅上传了元数据是不同结论。保留完整文件，比较可信同版本 DLL 的体积与结构，检查节区、资源和尾部数据是否存在异常填充，再关联实际加载路径与运行后行为。大型资源包、安装组件和合法插件也可能很大；Unit 42 的 DLL 劫持检测研究将异常文件大小列为筛选线索，而非单独定性依据。

LSASS 或高权限进程注入致盲

部分木马会尝试把代码写入 lsass.exe、winlogon.exe、services.exe、svchost.exe 等高权限或长期运行进程。这里需要区分两种目的：

访问 LSASS
  → 凭据、令牌或认证材料获取

注入安全相关 / 高权限宿主
  → 借用进程上下文、隐藏载荷或绕过部分用户态监控

注入本身不一定直接“关闭”安全产品，但可能通过以下方式形成致盲效果：

• 让恶意逻辑运行在安全产品较少重点关注的合法进程上下文中；
• 借助高权限进程访问安全组件、策略和受保护资源；
• 通过进程内执行、内存加载或线程控制，减少独立恶意进程暴露；
• 干扰用户态 Hook、事件采集或安全产品与目标进程之间的观测链路；
• 为后续停止服务、修改策略或加载驱动提供更高权限。

现代 Windows 对 lsass.exe 等目标可能启用 PPL、Credential Guard 等保护，因此注入未必成功。检测时应同时关注成功和失败事件：攻击者反复申请 PROCESS_VM_WRITE、PROCESS_CREATE_THREAD、PROCESS_DUP_HANDLE 等访问权限，即使最终返回拒绝，也能说明其正在尝试突破高价值进程边界。

重点关联：

提权 / 启用 SeDebugPrivilege
  → NtOpenProcess(LSASS 或其他高权限进程)
  → VirtualAllocEx / NtWriteVirtualMemory
  → APC、远程线程或线程上下文修改
  → 安全服务、遥测或后续防护能力异常

不能仅凭 OpenProcess(lsass.exe) 判定“安全产品被致盲”，需要查看目标进程是否为安全组件宿主、是否发生实际内存执行，以及之后是否出现采集缺失、告警不上报或保护策略失效。

白驱动与 BYOVD 致盲

BYOVD（Bring Your Own Vulnerable Driver）是攻击者携带合法签名但存在已知漏洞、设计缺陷或过高权限接口的驱动，并利用它获得内核级操作能力。与普通用户态注入相比，BYOVD 的危险之处在于它可能直接干预安全产品依赖的内核边界：

释放或加载异常驱动
  → 与驱动设备对象通信
  → 获取内核读写或进程操作能力
  → 终止 / 挂起安全进程、修改回调或绕过保护
  → 关闭、削弱或伪造安全产品状态

可能的致盲目标包括：

• 安全产品用户态服务和 Agent；
• 安全产品驱动、设备对象和内核回调；
• 受保护进程、进程句柄和线程控制；
• ETW、日志、文件过滤和网络过滤相关能力；
• EDR 自保护、隔离和响应模块。

常见线索包括 NtLoadDriver、服务注册、异常 .sys 文件、驱动设备对象创建，以及驱动加载后安全服务或遥测突然中断。需要注意，“签名有效”只说明驱动满足某种签名校验，不等于驱动安全；应结合驱动哈希、厂商、版本、漏洞状态、加载路径和使用时序判断。

修改签名中的未认证字段，改变文件哈希

文件整体 SHA-256 与 PE Authenticode 签名验证不是同一个摘要：前者覆盖文件的全部字节，后者按 PE 格式计算映像摘要，并依照签名结构处理证书表。因此，某些未被主签名认证的附加数据发生变化时，可以出现“文件 SHA-256 改变，但 Authenticode 仍验证有效”。

Check Point Research 对 2025 年银狐 BYOVD 活动的分析记录了一个具体案例：攻击者修改 WatchDog Antimalware 修补版驱动 wamsdk.sys（1.1.100）嵌入签名的 RFC 3161 时间戳未认证属性中的一个字节。这个字节不受主签名摘要覆盖，因此文件整体 SHA-256 发生变化，微软签名仍被验证为有效。这里是 wamsdk.sys；报告中较早使用的 amsdk.sys 是另一个版本的驱动，不要混为一谈。

原 wamsdk.sys：SHA-256 = A，签名 = Microsoft / Valid
        ↓ 修改签名中的未认证字段
变体 wamsdk.sys：SHA-256 = B，签名 = Microsoft / Valid

如果封禁规则只匹配原文件的完整哈希 A，变体 B 就不会命中该条规则；如果准入策略又粗略地把“签名有效”当成安全依据，就可能同时漏掉这个仍有风险的驱动。这并不意味着能随意修改驱动代码并保留有效签名，也不意味着微软易受攻击驱动阻止列表等机制仅凭哈希工作。

研判时应同时核对完整文件哈希、签名验证结果、签名者、驱动版本和实际加载行为。对异常同源变体，不应因为哈希不在旧 IOC 中或签名仍有效就直接放行；还要关联驱动设备访问及后续安全进程、遥测状态的变化。

检测重点：

• 用户目录、临时目录或随机路径释放并加载驱动；
• 非正常安装、更新或硬件管理流程触发驱动加载；
• 驱动加载后短时间内出现安全进程终止、句柄异常或遥测断层；
• 驱动不在企业软件清单、易受攻击驱动阻止策略或批准的硬件驱动范围内；
• 同一进程同时完成提权、驱动加载、服务操作和安全产品配置修改。

如果怀疑内核边界已被破坏，不应只依赖被影响主机上的用户态日志，应结合内核日志、驱动清单、网络侧心跳、中心平台接收情况和离线取证进行确认。

自编写内核驱动致盲

CN-SEC 的银狐“双链路攻击”文章在“3.3 自编写驱动：内核级杀软对抗”中描述了另一种思路：攻击者自行编写用于干预安全进程的驱动，用户态组件识别目标并向驱动发出请求，驱动尝试在内核态执行相关操作。文章还提到签名和 VMP 加壳。

这与 BYOVD 的区别是：BYOVD 滥用已有驱动的漏洞或危险接口；自编写恶意驱动则把攻击功能直接写进自己的内核组件。 两者都需要解决内核代码如何获得执行资格的问题。自编写本身不赋予加载权限，也不能保证能够终止所有受保护安全进程。

攻击者控制的高权限用户态组件
  ↓
携带自编写驱动，尝试通过目标主机的驱动准入检查
  ↓ 加载成功才成立
用户态组件向驱动请求操作目标安全进程
  ↓
驱动在内核态尝试干预安全组件
  ↓
核对安全服务、传感器、遥测和响应能力的实际变化

为什么可能没有在加载时被拦截

“新驱动没有命中已知名单”只能解释某一道检测为什么没命中，不能推出“Windows 或 EDR 认为它安全”。 驱动能否加载、是否被判可疑、是否被阻断，应分开看：

检查层次	判断的对象	自编写驱动可能出现的情况
加载权限与系统准入	调用主体权限、签名信任、代码完整性和已生效策略	不符合要求仍会拒绝加载，管理员权限也不自动豁免签名检查
已知驱动或恶意样本阻止规则	已知文件、签名者、证书、版本等规则	新样本可能尚未命中现有规则，但同一证书或签名者的封禁仍可能覆盖它
企业应用控制	是否属于批准的驱动、发布者或签名范围	明确的允许列表可以拒绝未经批准的新驱动，无须先识别其恶意功能
EDR 静态与信誉判断	文件内容、签名信誉、来源和环境上下文	合法签名是一个信号；加壳可能增加分析成本，也可能成为异常线索
EDR 运行时检测与自保护	谁加载、谁访问驱动、针对什么对象、后续发生什么	服务创建、异常加载、安全进程退出或遥测中断仍可能触发检测和处置

微软的驱动阻止规则说明明确包含已知漏洞、恶意行为和用于签署恶意软件的证书，并建议尽可能采用明确的允许列表。因此，cn-sec 的说法宜理解为对已知规则覆盖缺口的描述，而非自编写驱动通用免检。

签名有效为什么仍可能是恶意驱动

签名主要用于确认发布身份与内容完整性。它不证明驱动的每个功能都无害，也不代表签名者的后续行为都值得信任。微软曾公开调查经其签名流程签署的恶意驱动，并采取账户停用和 Defender 检测、阻断等措施；这说明签名信任链也需要持续审查。

同时，“购买普通代码签名证书并签名”不等于现代 Windows 就允许加载该驱动。实际要求取决于系统版本、更新、Secure Boot、签名类型和策略。微软的驱动签名要求说明了 Hardware Dev Center 签名要求；当前 Windows Driver Policy又收紧了适用系统对旧交叉签名驱动的信任，并区分审计与强制执行状态。不能把旧版本的加载条件直接套到所有主机。

HVCI 也不是“判断驱动意图是否恶意”的万能检测器。它强化代码完整性与内存执行约束，例如禁止可执行内核页同时可写；符合这些约束的驱动仍可能包含有害逻辑，故需要结合应用控制和行为检测。具体约束见微软的 HVCI 驱动兼容性说明。VMP 加壳不会产生有效签名，也不会让这些准入检查失效。

如何确认这次真的造成致盲

文章概括性的签名和示例代码，不足以证明某个具体样本通过了所有系统检查。分析时应保留驱动及其目录签名信息，核对签名链、证书状态、系统策略与 Code Integrity 日志，再确认驱动是否实际加载、请求是否执行成功，以及安全产品是否失去相应能力。

EDR 也可能已经记录异常，但策略仅告警、处置尚未发生或组件先遭破坏。应分别记录“未检出”“已告警未阻断”“驱动加载被阻止”和“加载后产生影响”，避免只凭安全进程退出就写成“全程无感”。

为什么木马会写入 Program Files

木马在完成提权后，有时会把自身或组件写入 C:\Program Files、C:\Program Files (x86) 或其子目录。常见动机不是“Program Files 天然安全”，而是利用它的目录外观、权限和软件生态：

伪装成已安装软件

Program Files 是用户和管理员习惯认可的软件安装位置。木马可以创建看似正常的产品目录、版本目录和组件结构，让文件更像正式安装的软件，降低人工排查时的异常感。

利用高权限和安装语义

普通用户通常不能直接向 Program Files 写入文件。木马选择该路径，往往说明它已经获得管理员、SYSTEM 或安装服务上下文，或者借助了一个本来就具备安装权限的进程。

因此，下面的组合比“文件位于 Program Files”本身更有价值：

提权 / 令牌操纵
  → 创建 Program Files 子目录
  → 写入 EXE、DLL、配置或驱动
  → 创建服务、计划任务或启动项

借用软件目录和加载关系

木马可能把黑 DLL、配置或后续模块放入某个软件目录，利用白加黑、DLL 搜索顺序或插件机制启动。也可能伪造软件名称、版本信息和目录层级，使进程路径看起来像合法产品。

降低清理和重启后的不确定性

相较于随机临时目录，Program Files 下的文件更可能被安装逻辑、服务、升级器或计划任务长期保留。木马还可能把主模块、配置、更新组件和备用载荷分开放置，形成持久化和恢复链。

不能把路径当作信任凭证

Program Files 不会自动赋予文件签名、白名单身份或系统信任。以下情况仍然应高度关注：

• 目录由用户目录进程、脚本解释器或异常安装程序创建；
• 文件没有有效签名，或签名者与产品目录不匹配；
• 原始文件名、产品名、版本信息与路径不一致；
• 同目录出现未签名 DLL、异常配置或刚落地的驱动；
• 文件写入后立即创建服务、计划任务、C2 连接或进程注入；
• 目录名称仿冒知名软件，但缺少完整安装文件和正常升级关系。

检测时应记录创建者、写入权限、父子进程、文件时间线、签名、哈希、模块加载和持久化关系，而不是简单把 Program Files 加入白名单。

抽象案例

反向利用软件限制策略

某个已取得高权限的进程没有终止任何安全软件，而是在系统策略区域创建多条“禁止运行”规则，目标集中指向若干安全产品的程序目录、服务组件和驱动路径。随后它触发策略刷新。

短期内，正在运行的部分组件可能看起来正常；但在服务重启、产品升级或主机重启后，系统会按策略拒绝相应组件加载。其危险之处在于，拦截动作由 Windows 自己执行，安全软件可能只表现为启动失败。

防守侧应关注：

• 非域策略引擎、非受管工具直接修改软件限制或应用控制策略。
• 短时间内批量写入多个安全厂商路径。
• 策略写入后紧跟强制刷新、服务重启或系统重启。
• 本地策略与域控制面、变更记录不一致。

阻断云端但保留本地外观

另一个场景中，攻击者新增出站阻断规则，只针对系统更新、安全产品更新和云端信誉地址。安全界面仍显示“实时保护已开启”，但特征更新停滞，未知文件无法查询信誉，告警也不能及时上传。

这类情况需要从网络控制面检查规则创建者、目标域名或服务、规则生效时间，并与终端最后更新时间和最后上报时间关联。

提权后的组合清场

更完整的攻击链可能是：

获得管理员 / SYSTEM
↓
枚举安全产品、服务、驱动和更新通道
↓
选择停用、策略封禁、网络阻断或驱动干预
↓
确认告警和自保护是否失效
↓
再执行凭据访问、持久化、横向移动或数据外传

所以安全产品异常往往不是孤立故障，而是提权之后、核心恶意动作之前的“清场”阶段。

检测框架

看“健康度”而不只看进程

安全产品健康度至少应覆盖：

层面	检查项
进程与服务	运行状态、退出原因、自保护、启动类型
驱动与传感器	加载状态、版本、回调或事件是否持续产生
策略	来源、版本、关键开关、排除项、最近修改者
内容更新	引擎、规则、病毒库和易受攻击驱动清单版本
网络	心跳、事件上传、信誉查询、更新通道
数据质量	事件速率、字段完整性、时间连续性、跨源一致性
响应	隔离、查杀、远程命令和回滚是否可用

高风险关联

以下时序组合应优先升级：

• 提权成功后立即枚举并修改安全产品。
• 用户可写目录进程修改系统级防护策略。
• 安全产品排除项新增后，同一路径马上出现新载荷。
• 异常驱动加载后，安全服务、日志或网络心跳消失。
• 防火墙、代理或 DNS 变化只影响安全与更新基础设施。
• 本地仍有事件，中心平台在同一时刻停止接收。
• 多家安全产品或多个组件被同一进程批量针对。

基线与误报

管理员、软件升级、故障修复和企业策略部署也会改变安全产品。收敛误报时应核对：

• 变更是否来自批准的管理平台或签名脚本。
• 是否有工单、维护窗口和对应操作者。
• 策略是否由域或 MDM 下发，而不是终端本地私建。
• 修改是否与正常升级版本、官方卸载流程一致。
• 动作之后是健康恢复，还是传感器和上报持续下降。

不要用静态进程白名单过滤全部管理工具。合法工具被非预期父进程、非预期账户或非维护窗口调用，同样值得检查。

调查与处置

调查顺序

1. 确认异常是单个组件故障、网络中断，还是多层能力同时失效。
2. 以最后正常心跳和第一条异常为时间锚点，查找提权、策略、服务、驱动和网络变化。
3. 对比本地与中心日志，确定是“没采到”还是“采到了但没传上去”。
4. 查明修改主体、父进程、用户、令牌、落地文件和远程来源。
5. 检查致盲之后发生的凭据访问、注入、持久化、横向移动和外传。
6. 从可信介质或受管控制面恢复策略与组件，并验证端到端遥测和响应能力。

处置原则

• 不要只手工重启安全服务；如果策略、驱动或网络阻断仍在，服务会再次失效。
• 不要只删除最初载荷；致盲通常为后续动作服务，必须扩大时间线和影响范围。
• 恢复前保存策略、注册表、驱动、日志和网络配置证据。
• 若内核或产品自保护可能已被破坏，优先隔离主机并从可信环境取证。
• 恢复后验证事件采集、中心上报、策略更新、信誉查询和远程响应，而不只是看 UI 变绿。

缓解

• 启用防篡改、HVCI 和易受攻击驱动阻止规则，并保持系统与产品更新。
• 把安全产品配置纳入受管控制面，监控本地策略与中心策略漂移。
• 对安全服务、驱动、策略、排除项和防火墙规则建立独立审计。
• 让关键日志实时转发到终端之外，避免主机失陷后唯一证据被清除。
• 使用独立网络监控验证终端遥测通道，发现“进程在线但数据消失”。
• 限制本地管理员，保护产品卸载口令、管理令牌和部署凭据。
• 对白加黑、CustomAction 和其他合法宿主保留行为分析，避免签名即全信任。

ATT&CK 对照

Technique	适用含义
T1562.001 Disable or Modify Tools	停止、修改、绕过或破坏安全工具
T1562.002 Disable Windows Event Logging	停止或削弱 Windows 事件记录
T1562.004 Disable or Modify System Firewall	篡改防火墙以阻断安全通道或放行攻击流量
T1562.006 Indicator Blocking	阻止或修改遥测、日志与检测所需信息
T1070 Indicator Removal	清除日志、文件或其他入侵痕迹

具体标签应跟随证据选择。例如新增防火墙规则以阻断安全云端时，可同时考虑防火墙修改和工具削弱；不要为了覆盖面把所有子技术都机械打上。

小结

安全产品致盲的本质，是破坏安全能力链，而不一定让安全软件消失。最危险的状态往往是：

进程还在
界面正常
但传感器不采、策略不执行、事件不上报、特征不更新

因此检测和恢复都必须从进程状态扩展到驱动、策略、日志、网络、数据质量和响应闭环，并把致盲前后的提权与后续攻击行为串成完整时间线。