基于某EDR组件滥用的白程序利用分析与教学

1. 引言

本文档基于一篇安全研究文章，详细剖析了一次针对某信服EDR（终端检测与响应）组件的安全发现与利用过程。核心是利用了EDR自身组件中一个缺乏校验的、带有合法签名的程序（lloader.exe），将其武器化为一个隐蔽的执行载体，用于加载恶意代码，并成功在安装了360“核晶”防护的系统上完成了权限提升操作。本教学旨在深入拆解其技术原理、攻击链条与防御启示，为安全研究人员及防御方提供参考。

2. 发现过程与技术背景

2.1 初始场景

攻击者在一次内网横向渗透测试中遭遇了部署某信服EDR的主机。常规的恶意脚本和木马文件一旦落地即被查杀，尽管通过免杀技术成功获得初步立足点，但可用的攻击路径有限。

2.2 关键发现：Lua脚本与解释器

在探查EDR安装目录时，攻击者发现目录下存在大量.lua脚本文件。这揭示了该EDR产品的部分核心逻辑是由Lua脚本驱动的。一个重要的安全假设随之产生：有脚本存在，就必然存在一个对应的解释器程序。

3. 定位“白程序”：lloader.exe

3.1 寻找脚本引擎

攻击者遍历目录，在所有的.exe和.dll文件中，最终锁定了一个名为lloader.exe的程序。此程序被确定为加载和执行上述Lua脚本的引擎。

3.2 程序属性分析

1. 数字签名：lloader.exe带有某信服公司的有效数字签名。在安全软件的信任模型中，带有合法厂商签名的进程通常被视为可信进程（即“白程序”或“白名单进程”），其行为会受到较低的限制或监控。
2. 功能验证：直接运行lloader.exe会返回与Lua相关的提示信息。当尝试向其传递一个Lua脚本文件时，后台产生了相应的活动。这证实了它是一个LuaJIT环境加载器。
3. 安全缺陷：最关键的安全漏洞在于，这个加载器只负责加载并执行Lua脚本，但对所加载脚本的内容、来源和签名没有任何校验机制。这意味着攻击者可以控制其执行任意Lua代码。

4. 武器化利用：构建Shellcode加载器

4.1 利用思路

既然lloader.exe是一个可被任意Lua脚本驱动的、有合法签名的进程，那么就可以将它改造成一个“带签名的父进程的Shellcode加载器”。这对于绕过安全软件的检测具有重要意义，因为许多安全产品对来自可信签名进程的恶意行为检测相对宽松。

4.2 技术实现

1. 编写恶意Lua脚本：攻击者编写了一个Lua脚本，其核心功能是加载并执行Shellcode。文中提到，攻击者原本希望直接在Lua中实现进程注入，但由于对Lua语法不熟悉，选择实现一个相对简单的加载器来加载预置的Shellcode。
2. 执行验证：通过lloader.exe执行这个恶意Lua脚本，成功弹出了计算器（calc.exe），证明了概念可行。这标志着一个合法的EDR组件进程，在攻击者控制下，执行了恶意操作。

4.3 攻击优势

• 信任规避：恶意行为的父进程是带有EDR厂商自身数字签名的可信进程，显著降低了被安全软件（特别是基于行为监控和父子进程链分析的产品）拦截的概率。
• 场景契合：EDR自身为了进行监控和响应，常常需要执行一些高权限操作（如杀进程、创建进程、写注册表），这与攻击者（红队）的部分行为模式相似，使得lloader.exe的行为在EDR看来可能不那么“异常”。

5. 高级利用：绕过“核晶”防护添加用户

5.1 挑战：360核晶防护

360的“核晶”防护是一种基于虚拟化技术的强力内核级防护，对系统的关键操作（如添加用户）有严格的拦截机制。在正常情况（无签名父进程掩护）下，添加用户的操作会被核晶直接阻断。

5.2 利用“白程序”突破

1. 加载恶意EXE：攻击者没有直接让Lua加载Shellcode，而是让lloader.exe（作为父进程）去加载并执行一个独立的、用于添加用户的恶意可执行文件。
2. 成功绕过：由于执行添加用户操作的进程是由带有合法签名的lloader.exe创建的，这个操作成功绕过了360核晶防护的拦截，实现了在受高强度防护的系统上添加后门账户。

文档提示：文章指出，攻击者曾拥有一个能在核晶下直接添加用户的工具，但该工具后来已被查杀。本次利用的核心创新在于使用了“白程序”作为加载器，而非利用了一个未公开的0day漏洞。

6. 技术总结与防御启示

6.1 攻击链复现

1. 信息收集：发现EDR使用未加密、无校验的Lua脚本作为逻辑组件。
2. 资产定位：找到对应的、带签名的Lua解释器程序lloader.exe。
3. 漏洞确认：验证该程序对加载的脚本内容无任何安全校验。
4. 载荷开发：编写能加载Shellcode或可执行文件的恶意Lua脚本。
5. 执行渗透：通过lloader.exe执行恶意脚本，以高信任度进程的身份运行攻击载荷，绕过包括核晶在内的主动防御。

6.2 漏洞根源

• 安全设计缺陷：可信组件（lloader.exe）缺乏代码签名验证机制，无条件执行外部脚本。
• 最小权限原则缺失：一个本应只用于加载内部逻辑脚本的组件，被赋予了过高的权限，且其行为未受到EDR自身的有效监控和限制。

6.3 防御建议（针对安全产品开发商与企业防御方）

1. 强化组件自身安全：

   • 强制代码签名：对于所有可执行脚本（Lua, Python, PowerShell等），加载器必须验证其数字签名，仅执行来自受信发布者的脚本。
   • 沙箱隔离：解释器/加载器进程应在沙箱或受限的AppContainer中运行，限制其网络访问、进程创建、文件写入等能力。
   • 资源控制：严格定义解释器可访问的目录和文件，防止其读取或加载非预期的脚本。

2. 实施纵深监控：

   • 行为监控无特权：安全产品对自身组件的监控应与其他进程一视同仁，甚至更加严格。任何进程（无论签名多可信）尝试加载Shellcode、进行进程注入、添加用户等敏感操作，都应触发告警或拦截。
   • 父子进程链分析：需要深入分析进程创建链的合理性。一个Lua脚本解释器去创建cmd.exe、rundll32.exe或直接加载未知EXE，是高度可疑的行为，无论父进程是谁。

3. 资产管理与攻击面缩减：

   • 最小化安装：在非必要的终端上，不安装EDR的管理端或调试组件。
   • 权限最小化：确保所有应用程序，包括安全软件组件，以所需的最小权限运行。

4. 红队视角的启发：

   • 在攻防演练和渗透测试中，应重点关注安全软件、管理软件、监控代理等“白程序”的安装目录，寻找是否存在可被滥用的脚本引擎、插件加载器、更新程序等。
   • 将“白程序利用”作为绕过应用控制、杀软行为监控和EDR的关键技术进行储备和研究。