ring3层摘取令牌致盲火绒

一、前言

今天就讲讲怎么ring3层致盲火绒吧，这是一个很老的技术，大概22年的时候就有公开文章进行讲解了，不过关它针对的是defend，在我实际测试中依然对火绒有效（2月份的时候就已经发现依然有效了，但是我一直不太想更新，哈哈，因为写东西也比较麻烦，再加上这个其实国内也有很多大佬师傅早就讲过了）。

二、背景介绍

这个技术大概是首发在elastic的一篇研究文章(https://elastic.github.io/security-research/whitepapers/2022/02/02.sandboxing-antimalware-products-for-fun-and-profit/article/），但是现在的话已经找不到了。现成的项目还能找到代码

pwn1sher/KillDefender最早放出来的 PoC，直接对 MsMpEng.exe 调用 OpenProcessToken + AdjustTokenPrivileges + SetTokenInformation ，把令牌权限全部移除并把完整性设为 Untrusted，Defender 会立即“哑巴”。需要 SYSTEM 权限才能运行。
仓库地址：https://github.com/pwn1sher/KillDefender
Octoberfest7/KillDefender
在前者基础上做了代码整理与稳定性改进，同样通过“剥光”令牌权限让 Defender 失效，也是 SYSTEM 权限前提。
仓库地址：https://github.com/Octoberfest7/KillDefender
Octoberfest7/KDStab
把 KillDefender 的剥令牌逻辑做成 Cobalt Strike 的 BOF（Beacon Object File），方便在红队行动中内存加载执行，进一步降低落地被杀风险。
仓库地址：https://github.com/Octoberfest7/KDStab

并且原来的文章我找到了pdf存档

https://archive.orkl.eu/60c5c1324abb7a0057fb05322fae83d783810ac2.pdf

三、简单介绍原理

Windows 令牌（Token）是一种安全凭证。它标识了你的身份以及你被允许执行的操作。通常情况下，当用户运行一个进程时，该进程会以该用户的令牌运行，并可以执行该用户能够执行的任何操作。令牌中一些最重要的数据包括：

用户身份
组成员身份（例如：Administrators）
特权（例如：SeDebugPrivilege）
完整性级别（Integrity level）

令牌是 Windows 授权的关键部分。每当 Windows 线程访问一个可安全对象（securable object）时，操作系统都会执行安全检查。它会将线程的有效令牌（effective token）与被访问对象的访问控制描述符（Access Control Descriptor, ACD）进行比较。

你可以在以下资源中了解更多关于令牌的内容：

Microsoft 访问令牌文档

Windows 提供的 OpenProcessToken 用于获取进程令牌的句柄。MSDN 文档声称，调用者必须拥有 PROCESS_QUERY_INFORMATION 权限；对受 PPL（Protected Process Light）保护的进程，则只能拿到 PROCESS_QUERY_LIMITED_INFORMATION——似乎意味着“拿不到完整令牌”。
但文档写得并不准确。实测表明，仅凭 PROCESS_QUERY_LIMITED_INFORMATION 就足以调用 OpenProcessToken 成功，把 PPL 进程的令牌句柄拿回来。James Forshaw 曾在一篇文章里用内核反编译代码解释过这一偏差：NtOpenProcessToken 实际只校验进程句柄的最低限度访问权，而不管你是不是“受限信息”级别。
拿到句柄只是第一步。令牌本身也是一个带有安全描述符的可受保护对象，后续任何操作（TOKEN_QUERY、TOKEN_WRITE、TOKEN_IMPERSONATE…）都要再走一次常规访问检查：系统会把调用线程当前有效令牌的权限，与目标令牌安全描述符里要求的访问权限做比对，只有比对通过才真正授予对应权限。换句话来说OpenProcessToken 的门槛比文档低。

总结成一句话就是，我们的Openprocess还是可以拿到PPL进程的令牌，我们可以将令牌的权限全部移除从而达到致盲的效果。（之前了）

用这种技术，攻击者可以强制移除杀软令牌中的所有特权，并将其完整性级别从 System 降至 Untrusted。

被削弱到 Untrusted 完整性级别后，受害进程将无法访问系统上的大多数可安全对象资源，从而在不终止进程的情况下悄然使其丧失能力。

Elastic从 2022 年 1 月 5 日向微软安全响应中心（MSRC）披露了这个漏洞，并提出了修复方案。微软他们在 2022 年 1 月 24 日回复称，他们认为该漏洞的严重程度为中等，不会通过安全更新来处理。不过，他们可能会在未来版本的 Windows 中处理这个问题。

当然这种思路对我们的非PPL进程也肯定有用（火绒）