C:\myapplication\myapplication.exe
      C:\myapp\subfolder\myapp.exe
      C:\SoftwareCompany\software.exe
      C:\myapplication\myapplication.dll
      C:\myapp\subfolder\myapp.dll
      C:\SoftwareCompany\software.dll
           

**一个实用的心智模型是：**

进程加载 libeay32.dll

→ 进程调用 OPENSSL_config(NULL)

→ OpenSSL 读取 openssl.cnf

→ engine 段导致尝试加载指定的 dll

→ Windows 加载器接受该 dll 及其依赖项

***如果缺少任何一步，你的 DLL 将无法加载。***

调试时可以使用的极简规则：

如果进程只加载 libeay32.dll，那还不够。
它还必须调用 OpenSSL 配置加载，并且不能禁用它。

- 它应该调用 OPENSSL_config 才能工作，或者
- CONF_modules_load_file，或者
- 未设置 OPENSSL_no_config。


没有签名检查。没有验证。只要进程调用 OPENSSL_config，任何指定的 DLL 都会被加载。
我们可以查询与 OpenSSL 相关的典型 DLL 名称，以枚举可能用于进一步测试的应用程序。我们想检查 DLL 的 OPENSSLDIR，以及进程是否调用了 OpenSSL_conf。
我们可以通过将文件哈希与此仓库中的列表进行比对来检查 OpenSSLDIR，或者获取一份与加密相关的 dll 副本，直接对 cryptodll（libeay32.dll 等）运行 openssldir_check。
我们还可以使用 ProcMon 检查进程是否调用了任何 openssl.cnf。如果我们在 procmon 中看到 openssl.cnf，那么就可以确定应用程序调用了它。在其他方法中，我们想要获取的是版本信息（位于 event.code 7 的字段中），以及它从哪个路径加载 openssl.cnf 文件——通过将文件哈希与此仓库中的列表进行比对，获取同一 DLL 的副本并手动检查。


**运行 openssldir_check.exe 时的示例**

`openssldir_check32.exe libeay32.dll`

`openssldir_check v1.0 by 0xm1rch`

**输出：**

`SSLeay_version() returned OpenSSL 1.0.1g 7 Apr 2014`

`SSLeay_version() returned OPENSSLDIR: "/usr/local/ssl"`

- 参考 https://github.com/mirchr/openssldir_check
> 使用本仓库中预编译的自定义修改版 openssldir_check 会得到类似输出。

> 输出显示 OpenSSL 版本为 1.0.1g，并且 OpenSSLDIR 设置为 **/usr/local/ssl**，这**非常有意思！**

> **Sysmon event.code 7** 会给出已加载的 OpenSSL DLL，以及 file.pe.file_version 字段中的 dll 版本信息。


#### 提权场景
1. 某个服务以 **SYSTEM** 身份运行并使用 OpenSSL
2. OpenSSL DLL 在启动时调用 openssl_conf 并读取 `C:\usr\local\ssl\openssl.cnf`，但该文件可被编辑或缺失
3. 如果低权限用户可以写入该文件夹，他们就可以：
   - 放置恶意的 `openssl.cnf`
   - 放置他们的 DLL
   - 等待服务重启
   - 代码以 **SYSTEM** 身份执行

> 结果：通过放置一个 openssl.cnf，使应用程序的 openssl dll 加载它，并最终加载自定义的“恶意”dll，从而实现本地权限提升。



### NSIS 安装程序/卸载程序漏洞

NSIS 是一个广泛使用的 Windows 安装程序框架。这里描述的问题是，当 NSIS 安装程序或卸载程序以提升的权限运行时，它可能会以普通本地用户可以干扰的方式使用 C:\Windows\Temp 下的临时目录。

在实践中，这意味着低权限攻击者可以控制安装程序信任的文件，例如临时插件文件或卸载程序文件，并将其转化为以 SYSTEM 身份执行代码。换句话说，弱点不是“安装程序以管理员身份运行”，而是安装程序的临时文件处理方式可能让非特权用户劫持提升权限的安装或卸载流程。

#### NSIS 安装程序中常见的 DLL

> 注意：其中一些是**官方 NSIS 插件**，另一些则是 NSIS 安装程序常用的**常见第三方插件**。  
> 看到这些 DLL 之一是一个线索，但并非安装程序使用 NSIS 的绝对证据。文件路径 `C:\Windows\Temp\*.tmp\*.dll` 是一个很强的指示。

| DLL | 典型用途 | 类型 | 备注 |
|---|---|---|---|
| `System.dll` | 从 NSIS 脚本调用 Win32 API 和外部 DLL 函数 | 官方 NSIS 插件 | NSIS 最强的指示之一 |
| `nsDialogs.dll` | 构建自定义安装程序对话框和控件 | 官方 NSIS 插件 | 常见于现代 NSIS 安装程序 |
| `nsExec.dll` | 执行控制台命令并捕获输出 | 官方 NSIS 插件 | 常用于静默辅助命令 |
| `StartMenu.dll` | 让用户选择开始菜单文件夹 | 官方 NSIS 插件 | 常见于经典安装程序 |
| `LangDLL.dll` | 显示语言选择对话框 | 官方 NSIS 插件 | 常出现在多语言安装程序中 |
| `Banner.dll` | 在安装步骤中显示横幅/进度 UI | 官方 NSIS 插件 | 主要是装饰性 |
| `InstallOptions.dll` | 根据 INI 定义创建旧式自定义页面 | 官方 NSIS 插件 | 已在很大程度上被 `nsDialogs.dll` 取代 |
| `UserInfo.dll` | 获取当前用户/账户的信息 | 官方 NSIS 插件 | 用于权限或账户检查 |
| `Dialer.dll` | 管理拨号/网络连接行为 | 官方 NSIS 插件 | 主要是遗留功能 |
| `Math.dll` | 为 NSIS 脚本提供算术辅助功能 | 官方 NSIS 插件 | 在较新脚本中较少需要 |
| `NSISdl.dll` | 从互联网下载文件 | 官方 NSIS 插件 | 较旧的下载插件；常被 `inetc.dll` 取代 |
| `Splash.dll` | 显示启动画面 | 官方 NSIS 插件 | 主要是遗留/装饰性 |
| `AdvSplash.dll` | 显示更高级的启动画面 | 常见 NSIS 插件 | 作用类似于 `Splash.dll` |
| `BgImage.dll` | 在安装程序 UI 中显示背景图像 | 官方/常见 NSIS 插件 | 主要是装饰性 |
| `inetc.dll` | 通过 HTTP/FTP 下载文件 | 常见第三方 NSIS 插件 | 在 Web 安装程序中非常常见 |
| `InetLoad.dll` | 从互联网下载文件 | 常见第三方 NSIS 插件 | `NSISdl.dll` / `inetc.dll` 的替代品 |
| `UAC.dll` | 处理提权和 UAC 相关行为 | 常见第三方 NSIS 插件 | 很强的 NSIS 相关线索 |
| `AccessControl.dll` | 更改文件/文件夹 ACL 和权限 | 常见第三方 NSIS 插件 | 用于管理员敏感安装 |
| `Registry.dll` | 高级 Windows 注册表操作 | 常见第三方 NSIS 插件 | 在某些情况下比内置注册表命令更强大 |
| `ShellLink.dll` | 创建或编辑 Windows 快捷方式（`.lnk`）文件 | 常见第三方 NSIS 插件 | 快捷方式管理辅助工具 |
| `SimpleFC.dll` | 比较文件或检查文件差异 | 常见第三方 NSIS 插件 | 实用/辅助插件 |
| `FindProcDLL.dll` | 检测某个进程是否正在运行 | 常见第三方 NSIS 插件 | 常用于升级前 |
| `KillProcDLL.dll` | 终止正在运行的进程 | 常见第三方 NSIS 插件 | 常见于卸载程序/更新程序 |
| `NScurl.dll` | 使用 curl 风格功能下载/传输数据 | 常见第三方 NSIS 插件 | 更新/更强大的网络辅助工具 |
| `ZipDLL.dll` | 处理 ZIP 归档的提取或创建 | 常见第三方 NSIS 插件 | 归档实用工具 |
| `unzipdll.dll` | 提取 ZIP 归档 | 常见第三方 NSIS 插件 | 较旧的归档插件 |
| `untgz.dll` | 提取 `.tar.gz` 归档 | 常见第三方 NSIS 插件 | 较少见，但在某些软件包中出现 |
| `VPatch.dll` | 应用二进制补丁/更新 | 常见 NSIS 相关插件 | 常用于补丁安装程序 |
| `CabDLL.dll` | 处理 CAB 归档 | 常见 NSIS 相关插件 | 主要见于较旧的打包工作流 |
| `nsJSON.dll` | 解析或生成 JSON 数据 | 常见第三方 NSIS 插件 | 在较新的脚本化安装程序中更常见 |
| `StdUtils.dll` | 用于 NSIS 的通用辅助实用工具 | 常见第三方 NSIS 插件 | 常用于 OS/版本/路径辅助 |
| `ExecDos.dll` | 执行命令，并对 I/O 和等待有更好的控制 | 常见第三方 NSIS 插件 | `nsExec.dll` 的替代/扩展 |

#### 更强的 NSIS 指示

以下 DLL 尤其能暗示 NSIS：

- `System.dll`
- `nsDialogs.dll`
- `nsExec.dll`
- `LangDLL.dll`
- `StartMenu.dll`
- `NSISdl.dll`
- `inetc.dll`
- `UAC.dll`

#### 注意

一些安装程序会将这些 DLL 临时解压到类似以下文件夹中：

- `$PLUGINSDIR`

因此它们可能只在运行时出现，而不是在磁盘上安装程序可执行文件旁边。


### DotLocal 重定向漏洞
**DotLocal 重定向滥用是一种 Windows DLL 劫持问题，其中可写的应用文件夹让攻击者诱使合法程序优先加载恶意 DLL**

DotLocal 重定向漏洞滥用 Windows 内置的 .local / DotLocal DLL 重定向功能。Windows 通过遵循名为 App.exe.local 的文件或文件夹来支持 DLL 重定向；当它存在时，加载器会首先在可执行文件所在文件夹或该 .local 文件夹中查找 DLL，而且即使指定了完整 DLL 路径，这也可能适用。Microsoft 将此记录为用于重定向 DLL 加载的合法功能。

为什么它会成为漏洞：如果攻击者可以写入可执行文件所在目录（用户可写路径），或写入特权进程使用的临时解压目录，他们就可以创建 Target.exe.local 文件夹，并将恶意 DLL 放在 Windows 会优先选择的位置。这会把该功能变成 DLL 劫持，因此受信任进程会加载攻击者的库，而不是预期的库。

#### 手动控制
对于位于全局可写路径中的已识别高权限进程，如果它们可能易受 DotLocal 重定向影响，就应进行调查。如果你查询它们并找到应用程序，请使用 ProcMon 做最后一项控制，查看进程是否尝试从创建的 .exe.local 文件夹加载库。你可以使用 GetSxsPath 工具确定完整文件路径。如果存在漏洞，Procmon 应显示指向 .exe.local 目录的 NAME NOT FOUND / PATH NOT FOUND 事件。根据公开报告，应用程序在安装过程中尤其容易受到攻击。

**一个很好的经验法则是：**
ProcMon 可以提供 .local 探测的证据，但没有可见的 .exe.local 未命中并不能证明应用不易受影响。尤其是对于 comctl32.dll，跟踪通常反映的是 manifest/SxS 绑定，而不是简单的应用文件夹 DLL 搜索。


#### 如果程序加载：

`C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.19041.1110_none_60b5254171f9507e\comctl32.dll`

#### 检查这个：

`C:\Path\To\Application.exe.local\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.19041.1110_none_60b5254171f9507e\comctl32.dll`

**确定 SxS DotLocal DLL 劫持的重定向路径** - https://gist.github.com/rxwx/1717e95e5ec11bea12d33e93a3832508

#### DotLocal Wiz 安装程序
**WiX Burn EXE bootstrapper** 受影响版本 >= 4、< 4.0.4、< 3.14.0。这会影响任何使用 WiX 安装程序框架构建的安装程序。
WiX 还允许作者替换默认图标，并使用原版 WixStdBA UI 或自定义 bootstrapper 应用程序，因此 EXE 可以被品牌化，使其看起来像供应商而不是“WiX”。

##### 详情
如果 bundle 不是以管理员身份运行，则会使用用户的 TEMP 文件夹，而不是系统 TEMP 文件夹。某个实用工具能够监控用户 TEMP 文件夹的变化，并在 .be 文件夹创建时立即将自己的 DLL 放入 .be/.Local 文件夹。当 burn 引擎提权时，恶意 DLL 会获得提升的权限。

> **参考** https://github.com/wixtoolset/issues/security/advisories/GHSA-7wh2-wxc7-9ph5

“单独的 wixstdba.exe 进程是很好的 WiX Burn 指纹，但受影响版本最强的指示是 Burn 引擎版本本身：如果它标识为 <3.14.0 或 4.0.0–4.0.3，则存在漏洞。”


## 先决条件
配置良好的 SYSMON 配置，用于捕获感兴趣的事件，例如针对用户可写路径和上述注册表配置单元的 event.code 1、7、11 和 13。
 - https://github.com/SwiftOnSecurity/sysmon-config
 - https://github.com/olafhartong/sysmon-modular

为部分 Windows 事件启用高级审计。

必须显式启用事件 ID 4688（进程创建）才能记录新创建的进程。
默认情况下，它不会捕获用于启动进程的命令行；必须在安全策略中专门启用此功能。

计划任务 - 4698 默认未启用。


## ACL ⭐
### 🔹 一些覆盖已登录用户的常见 ACL 主体

| 主体               | 描述                                                                 |
|--------------------------|-----------------------------------------------------------------------------|
| **Everyone**             | 所有用户，包括 Guest（在较旧 Windows 版本中甚至包括 Anonymous Logon）。范围非常广，通常限制为读取访问。 |
| **Authenticated Users**  | 任何已成功登录的账户（本地或域）。不包括匿名用户。 |
| **BUILTIN\Users**        | 机器上的本地 **Users** 组。包括所有标准（非管理员）本地账户。 |
| **INTERACTIVE**          | 任何**在控制台本地登录**的用户（键盘/会话）。可用于区分本地访问与远程访问。 |
| **COMPUTERNAME\\Username** | 该计算机上的特定**本地账户**（例如 `LAPTOP01\Bob`）。权限仅在该用户在本地登录时适用。 |
| **DOMAIN\\Username**     | 特定**域账户**（例如 `CORP\Alice`）。权限会跟随用户应用于所有加入域的机器。 |


### 📑 ACL 属性（一些值得关注的内容）

访问控制列表（ACL）属性定义用户或组可以对文件或文件夹执行哪些操作。  
以下是一些值得注意的关键属性：

| 属性 | 名称/含义           | 为什么有意思                                                                 |
|-----------|--------------------------|--------------------------------------------------------------------------------------|
| **F**     | 完全访问              | 授予**所有可能的权限**（读取、写入、执行、删除、更改权限、取得所有权）。等同于“所有者级”控制。 |
| **M**     | 修改访问            | 允许读取、写入和删除文件/文件夹，但**不能更改 ACL** 或所有权。普通用户最常见。 |
| **W**     | 只写访问        | 用户可以**创建或修改内容**，但不能读回。很少见，但在“投递箱”场景中有用（例如安全文件提交）。 |
| **WD**    | 写入数据/添加文件    | 特别允许**在目录中创建或写入文件**。对于能够在文件夹内添加或覆盖文件至关重要。 |
| **AD**    | 追加数据/添加子目录 | 对文件：将数据追加到文件末尾（不能覆盖）。对文件夹：在其中创建新的子目录。 |


## 误报
#### 执行你的查询，微调它们，最后基于它们生成告警。 
你可能需要做一些白名单处理（参见下面 ProgramData 中的典型路径）。思路是查询典型的用户可写路径，但有时这些（文件或文件夹）具有正确的 ACL 设置。如果攻击性思维无法帮助提权——就将它们加入白名单。
过滤掉不太有意思的那些：具有正确 ACL 的、随机化文件名的（过滤掉文件夹）。我们希望减少噪声并建立基线。重要的是在验证它不是漏洞之后再做这件事。这样你就不会错过每个客户端上都存在的易受攻击的计划任务。


## 白名单
你很可能需要将查询加入白名单。进行狩猎，微调查询，并基于它们生成告警，以捕获你尚未查看过的新事件。
##### 很可能需要白名单：
      C:\ProgramData\Microsoft
      C:\ProgramData\Package Cache
      C:\ProgramData\Packages
      等等。

其他可能需要白名单的内容，可能很常见，是硬件相关驱动程序和类似具有随机化名称的东西。
      

## 方法论
不要忘记在你的“日志保留期”时间范围内进行查询。
一个好的方法论是最初查询较短的时间范围，然后逐步增加。
1) 1 天
2) 1 周
3) 2 周
4) 1 个月
5) 2 个月
6) 等等..

进行狩猎并检查有意思的那些，然后微调并加入白名单……最后基于它们生成告警，以捕获新事件。

## 提示与技巧
如果由于 ACL 正确而无法替换二进制文件。检查文件夹权限，以及你是否有权限写入文件。
检查可执行文件是否尝试加载任何不存在的 dll。如果是，则创建它们，你就获得了代码执行。如果由于它是正在运行的进程而无法替换二进制文件。检查可能的 DLL 侧加载，或者检查你作为普通用户是否有权限重启该服务本身。另一种方法是检查你作为普通用户是否可以执行一次“关机”，并在最后一秒逃逸。启动关机流程会停止进程，如果你从中脱离，可能能够替换已终止进程的二进制文件。如果服务处于 Autostart 模式，而你没有权限启动/停止该服务，你可以检查是否拥有 SeShutdownPrivilege，如果有，则使用 shutdown /r /t 0 启动重启。

如果某个服务正在生成进程，并且无法替换二进制文件，该二进制文件也不会尝试加载任何缺失的 DLL。不要放弃——也许路径未加引号，而你有写入权限，可以利用这一点？

逐层构建你的查询……因此检查服务/计划任务的创建，检查父进程为服务或计划任务相关进程（带 Schedule 参数的 svchost.exe）的进程创建。可能某些系统创建了服务或计划任务，但二进制路径等不存在，进程创建从未发生。但漏洞仍然存在，并且可以生成与之相关的不同事件。

为了减少查询负载（性能）以及可能减少白名单需求……将客户端/服务器查询分开可能是个好主意。因此一组查询仅用于客户端端点，另一组相同集合用于服务器端点。

由 SYSTEM 发起的通用进程创建是高价值查询。它捕获许多场景……除了服务和 schtask 生成子进程之外，它还会捕获 msiexec.exe 生成子进程。它还会捕获来自 c:\windows\ccmcache 的可执行文件从用户可写路径生成子进程。如果我们要按漏洞对可执行文件排序，我仍然会说 services.exe 与软件错误配置相关，而 schtasks 更多是管理员错误配置……

如果你尝试了所有查询但没有成功。如果你想更深入地狩猎，并做更多工作——就去查看 services.exe 和 schtasks（带 Schedule 参数的 svchost.exe）的每一个子进程，无论它们在哪里。枚举企业环境，并查找位于典型管理员保护路径（Program Files 和 Program Files (x86)）中的那些。软件供应商即使在典型受保护路径中搞砸 ACL 的情况也比你想的更常见。使用进程创建事件以及服务和计划任务的事件。对于计划任务——查询每个 Command 字段和 Argument 字段。Argument 字段可能指向用户可写路径或 C 盘根目录中的脚本文件。Command 字段可能指向具有不安全 ACL 的二进制文件。你也可以查看 C:\PROGRA~3，它是 C:\ProgramData 的 8.3 短名称（DOS）表示。

## 卸载进程
如果用户可以触发安装，他们也很可能可以触发卸载。无论文件路径在哪里，卸载进程都值得关注。
如果 ACL 不正确——替换二进制文件很可能会造成麻烦。
还可以使用 Sysmon event.code:11 查询典型卸载文件的文件创建。
我们这样做是为了在不信任进程创建事件的情况下捕获每一个卸载程序。这是因为用户实际上并不常卸载已安装的应用程序……他们只是不关心，因此更容易错过一些存在但从未被触发的卸载事件。

### 卸载进程名称示例
#### 常见通用名称uninstall.exe – 最通用且广泛使用。
          unins000.exe、unins001.exe – 常见于 Inno Setup 安装程序。
          unwise.exe – 常用于较旧的 Wise Installer 软件包。
          uninst.exe – 缩短版本，常见于旧版软件。
          uninstaller.exe – 稍长、更具描述性的变体。
          remove.exe – 有时用于最小化安装程序。
          setup.exe（带 /uninstall 或 /remove 参数）– 某些应用复用安装程序可执行文件进行卸载。
          appname_uninstall.exe（例如 chrome_uninstall.exe）
          update.exe（带 --uninstall）– 见于 Slack 或 Discord 等使用 Squirrel 安装程序的应用。

#### 值得考虑的模式

          *_uninstall.exe – 许多应用会加上应用名前缀，例如 teams_uninstall.exe、zoom_uninstall.exe。
          *_cleanup.exe – 清除工具通常有 cleanup 变体，例如 driver_cleanup.exe。
          *_remover.exe – 另一种常见的杀毒软件/厂商命名风格。


## 加载时执行代码的 PE / 二进制文件
### 考虑在 windows/sysmon 日志和 procmon 日志中查询列表中的项
| 扩展名 | PE 类型 | 加载时执行代码？ | 入口点 / 机制 | 备注 |
|-----------|---------|--------------------------|-------------------------|-------|
| `.exe` | PE 可执行文件 | 是 | PE `AddressOfEntryPoint` | 可执行文件启动时代码开始运行 |
| `.dll` | PE DLL | 是 | `DllMain` / TLS 回调 | DLL 加载到进程时代码可执行 |
| `.sys` | PE 内核驱动 | 是 | `DriverEntry` | 驱动加载时驱动初始化代码执行 |
| `.scr` | PE 可执行文件 | 是 | PE `AddressOfEntryPoint` | 本质上是一个可执行文件；`.scr` 主要是一种约定 |
| `.cpl` | PE DLL | 是 | `DllMain` + `CPlApplet` | 由控制面板基础结构加载 |
| `.ocx` | PE DLL / ActiveX | 是 | `DllMain` + COM/ActiveX 入口点 | 加载时发生 DLL 初始化 |
| `.drv` | PE DLL / 旧式驱动 | 通常 | `DllMain` 或驱动特定入口点 | 取决于具体的 `.drv` 类型 |
| `.efi` | PE/COFF EFI 二进制文件 | 是 | EFI 入口点 | 由 UEFI 加载时代码执行 |
| `.ax` | PE DLL | 是 | `DllMain` + DirectShow 接口 | 加载时发生 DLL 初始化 |
| `.acm` | PE DLL | 是 | `DllMain` + ACM 入口点 | 作为音频压缩管理器编解码器加载 |
| `.ime` | PE DLL | 是 | `DllMain` + IME 入口点 | 加载时发生 DLL 初始化 |
| `.tsp` | PE DLL | 是 | `DllMain` + TAPI 入口点 | 加载时发生 DLL 初始化 |
| `.pyd` | PE DLL | 是 | `DllMain` + Python 模块初始化 | 原生 Python 扩展 |
| `.node` | PE DLL | 是 | `DllMain` + Node.js 插件初始化 | 原生 Node.js 插件 |
| `.xll` | PE DLL | 是 | `DllMain` + Excel XLL 入口点 | 由 `EXCEL.EXE` 加载 |
| `.wll` | PE DLL | 是 | `DllMain` + Word 加载项加载 | 由 `WINWORD.EXE` 加载 |



## 脚本文件
### 考虑查询列表中的项
| 扩展名 | 语言 / 类型           | 用途 / 用法                                         | 执行上下文                                          |
|-----------|---------------------------|---------------------------------------------------------|------------------------------------------------------------|
| .bat      | 批处理脚本               | 旧式命令行自动化任务、简单脚本     | `cmd.exe`（命令提示符）                                  |
| .cmd      | 批处理脚本（NT 风格）    | 类似于 `.bat`，在基于 NT 的系统上更受青睐         | `cmd.exe`（命令提示符）                                  |
| .vbs      | VBScript                   | 自动化任务、登录脚本、管理脚本           | Windows Script Host（`wscript.exe`、`cscript.exe`）          |
| .vbe      | VBScript（编码）         | 用于混淆的 `.vbs` 编码版本              | Windows Script Host（`wscript.exe`、`cscript.exe`）          |
| .ps1      | PowerShell 脚本          | 现代 Windows 自动化和配置任务       | PowerShell（`powershell.exe`、`pwsh.exe`）                   |
| .js       | JScript                    | 微软用于 WSH 任务的 JavaScript 版本          | Windows Script Host（`wscript.exe`、`cscript.exe`）          |
| .jse      | JScript（编码）          | 用于混淆的 `.js` 加密版本               | Windows Script Host（`wscript.exe`、`cscript.exe`）          |
| .wsf      | Windows 脚本文件（XML）  | 以 XML 格式混合 VBScript、JScript、其他脚本       | Windows Script Host（`wscript.exe`、`cscript.exe`）          |
| .wsh      | Windows Script Host 设置 | WSH 脚本的配置设置                  | Windows Script Host（`wscript.exe`、`cscript.exe`）          |
| .jar      | Java 归档               | 打包为单个文件的 Java 应用程序             | `java.exe`（控制台）/ `javaw.exe`（无控制台窗口）       |
| .hta      | HTML 应用程序（HTA）     | 使用 HTML、CSS 和 JScript/VBScript 的基于 GUI 的 Windows 脚本 | `mshta.exe`（Microsoft HTML 应用程序宿主）          |
| .com      | MS-DOS 应用程序 / DOS 可执行文件 | 旧式可执行程序、小型命令行实用工具 | 作为程序直接执行；在现代 Windows 上，经典 16 位 .com 程序在 32 位 Windows 上通过 NTVDM 运行，在 x64/ARM Windows 上不受原生支持 |
| .chm     | 已编译 HTML 帮助          | Windows 程序的离线帮助/文档文件   | `hh.exe`（Microsoft HTML 帮助查看器）                           |

## 启动/登录脚本

启动和登录脚本（以及关机或注销）是自动运行的自动化脚本（gpscript.exe），在加入域的计算机上或用户登录时运行，它们通常通过 Windows Active Directory 环境中域控制器上的组策略对象（GPO）部署。

启动/关机
- 运行身份：Local System 账户（高权限）。

登录/注销
- 运行身份：当前用户（如果是管理员则为高权限）。
### 常见用途：
- 为所有用户映射网络驱动器
- 安装软件
- 应用系统范围设置
- 启动或配置服务
- 运行脚本或可执行文件

### 受影响的注册表配置单元

当启动/登录脚本通过 GPO 运行时：

| 配置单元 / 路径 | 用途 |
|-------------|---------|
| HKCU\Software\Microsoft\Windows\CurrentVersion\Group Policy\Scripts\Logon | 跟踪用户登录脚本、其执行顺序、状态、上次运行时间和参数。 |
| HKCU\Software\Microsoft\Windows\CurrentVersion\Group Policy\Scripts\Logoff | 对注销脚本的类似跟踪。 |
| HKLM\Software\Microsoft\Windows\CurrentVersion\Group Policy\Scripts\Startup | 启动脚本（适用于所有用户）的跟踪信息。 |
| HKLM\Software\Microsoft\Windows\CurrentVersion\Group Policy\Scripts\Shutdown | 关机脚本信息。 |

#### 在 gpscript.exe 的子进程中查找脚本和可执行文件的用户可写路径，或可写网络共享或通用（SYSVOL）。 
阅读所运行的脚本，查看是否存在任何错误配置，例如其他用户可写路径或不存在或包含敏感信息的路径。查找可能使用的密码（net use z: \\server\share /user:domain\username password）或其他敏感信息。 

**登录脚本错误配置类别**
- SS1 – 明文凭据
- SS2 – 不安全的权限（普通用户可修改的登录脚本）
- SS3 – 不存在的共享（可能可由普通用户创建）
- SS4 - 具有登录脚本的管理员

**登录脚本错误配置**

1. SS1 - 登录脚本中的明文凭据
2. SS2 - 不安全的共享权限
3. SS2 - 不安全的文件权限
4. SS2 - 不安全的 NETLOGON/SYSVOL 权限
5. SS2 - 不安全的登录脚本权限
6. SS2 - 不安全的 GPO 登录脚本权限
7. SS3 - 不存在的共享
8. SS4 - 具有登录脚本的管理员
9. SS4 - 具有从不存在共享映射的登录脚本的管理员



## MSIExec / MSI 修复
##### 我们的测试在能够生成 edge 并突破到 cmd 提示符的场景中，没有产生任何权限提升的结果。这可能是因为基于 chromium 的浏览器会模拟用户/限制渲染进程以 SYSTEM 身份运行，并且不允许 internet explorer/edge 以 SYSTEM 用户生成 cmd 或其他进程。我们相信，如果未安装基于 chromium 的浏览器（如 firefox）或较旧版本。如果你能生成此类进程并从中突破到命令提示符，则可能实现权限提升。

如果你想枚举与此相关的可能事件，可以查询以 msiexec.exe 为父进程，并以 cmd.exe 或 conhost.exe 或 powershell.exe 或 pwsh.exe 为子进程的事件。
联系你的查询得到结果的用户，询问他们安装/修复了什么。你还可以检查 event.provider: "MsiInstaller" 和 event.code: (1033 OR 11707) 或类似内容，以获取有关同一时间戳附近安装了哪个 msi 安装程序的更多上下文。
你也可以自己在 Software Center 中尝试此操作，安装应用程序并查找命令提示符，你可以在它们消失之前通过在窗口中标记一个区域来暂停它们。然后使用下面链接中提到的相同技术突破。



##### 示例查询```
(event.provider: "Microsoft-Windows-Sysmon" AND event.code: 1 AND winlog.event_data.IntegrityLevel: System AND process.parent.name: msiexec.exe AND process.name: (cmd.exe OR conhost.exe OR powershell.exe OR pwsh.exe))
OR
(event.provider: Microsoft-Windows-Security-Auditing AND event.code: 4688 AND winlog.event_data.TokenElevationType: "%%1936" AND winlog.event_data.MandatoryLabel: "S-1-16-16384" AND process.parent.name: msiexec.exe AND process.name: (cmd.exe OR conhost.exe OR powershell.exe OR pwsh.exe))