环境变量劫持与执行链污染分析

环境变量劫持与执行链污染分析

环境变量在开发和运维中太常见，以至于很多人默认把它们当成“配置细节”。但在攻击者眼里，环境变量既可以是凭据仓库，也可以是执行入口，甚至还是提权原语。

真实事件里，环境变量相关问题大致分成三类：

  1. 敏感材料泄露 例如 .env 里直接存放数据库口令、云平台 Access Key。
  2. 执行路径劫持 例如通过 PATH、Windir、SystemRoot 把程序导向恶意目录或恶意 DLL。
  3. 运行期环境注入 例如利用 GCONV_PATH、LD_PRELOAD、容器环境变量，把原本正常的程序带到恶意执行流里。

0x01 公开案例一：暴露的 .env 文件导致 AWS 大规模勒索与外传

Unit 42 在 2024 年公开的一起云侧事件中指出：

  • 攻击者通过扫描公开暴露的 .env 文件
  • 获取 AWS IAM Access Key 等敏感凭据
  • 进入受害者云环境
  • 继续实施大规模勒索与数据外传

这个案例非常适合作为环境变量专题的开篇，因为它说明了一个现实问题：

  • .env 并不只是“开发配置文件”
  • 它在攻击者视角里就是现成的认证材料仓库

公开来源：

0x02 公开案例二：PATH 环境变量参与 DLL 搜索顺序劫持

Unit 42 在 2024 年关于 DLL Hijacking 的文章中明确提到：

  • 攻击者可以修改 PATH
  • 将自己可写的恶意目录插入 DLL 搜索顺序
  • 合法程序随后会优先加载攻击者控制的 DLL

其中一个非常实战的点是：

  • 某些 Python 安装目录在默认情况下权限过松
  • 若这些目录出现在 PATH 中
  • 就可能被低权限用户植入恶意 DLL，形成提权或执行劫持

公开来源：

0x03 公开案例三：Windir/SystemRoot 变量可被用于提权

Elastic 的预置检测规则里专门有一条关于：

  • Windir
  • SystemRoot

环境变量被异常修改的检测。原因是某些提权链会通过篡改这些变量，把高权限程序导向攻击者控制的目录。

这类问题的价值在于：

  • 看起来只是注册表里的一个环境变量
  • 但实际上可能会影响后续高权限执行路径

公开来源：

0x04 公开案例四：pkexec / GCONV_PATH 是 Linux 环境变量提权经典原语

虽然这是漏洞利用而不是传统持久化，但 pkexec / GCONV_PATH 的案例很适合说明环境变量在 Linux 里的危险性：

  • 攻击者通过设置异常环境变量
  • 影响高权限程序加载路径
  • 从而实现本地提权

这类案例提醒我们：

  • Linux 取证不能只看文件和进程
  • 还要看环境变量是否被临时注入、持久化污染或用于提权

公开参考：

  • Elastic detection guidance for pkexec environment hijack

0x05 环境变量取证时要重点区分的三类对象

1. 配置型变量

例如：

  • .env
  • application.properties
  • 容器 ENV
  • CI/CD Secret 注入

重点关注：

  • 明文密码
  • API Key
  • Access Key
  • 数据库连接串

2. 执行路径型变量

例如：

  • PATH
  • PATHEXT
  • Windir
  • SystemRoot
  • LD_LIBRARY_PATH

重点关注：

  • 是否被插入用户可写目录
  • 是否偏离系统默认值
  • 是否与 DLL / SO / EXE 劫持相关

3. 利用型变量

例如：

  • GCONV_PATH
  • LD_PRELOAD
  • 各类 Loader 相关环境变量

重点关注：

  • 是否在攻击时间窗内临时出现
  • 是否只在某个高权限进程前后出现

0x06 Windows 现场排查命令

1. 查看机器级与用户级环境变量

[System.Environment]::GetEnvironmentVariables("Machine")
[System.Environment]::GetEnvironmentVariables("User")

2. 查看注册表中的环境变量

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment"
reg query "HKCU\Environment"

3. 重点核查 PATH / Windir / SystemRoot

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" /v Path
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" /v windir
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" /v SystemRoot
reg query "HKCU\Environment" /v Path
reg query "HKCU\Environment" /v windir
reg query "HKCU\Environment" /v SystemRoot

4. 查用户可写目录是否被插入 PATH

$machinePath = (Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Environment").Path
$userPath = (Get-ItemProperty "HKCU:\Environment" -ErrorAction SilentlyContinue).Path
$allPaths = @($machinePath, $userPath) -join ';'
$allPaths -split ';' | Sort-Object -Unique

重点人工关注：

  • %TEMP%
  • %APPDATA%
  • C:\Users\Public
  • Python / Node / 自定义工具目录

5. 查 .env、云凭据与开发配置

Get-ChildItem C:\ -Recurse -Force -ErrorAction SilentlyContinue |
  Where-Object {$_.Name -in '.env','credentials','config'} |
  Select-Object FullName, LastWriteTime, Length

0x07 Linux 现场排查命令

1. 查看当前环境与可疑变量

env | sort
printenv | egrep 'PATH|LD_LIBRARY_PATH|LD_PRELOAD|GCONV_PATH|AWS_|AZURE_|GOOGLE_|TOKEN|PASSWORD'

2. 查持久化污染位置

grep -RInE 'PATH=|LD_LIBRARY_PATH|LD_PRELOAD|GCONV_PATH|AWS_ACCESS_KEY_ID|AWS_SECRET_ACCESS_KEY|TOKEN|PASSWORD' \
  /etc/profile /etc/profile.d /etc/environment /etc/bash.bashrc /root/.bashrc /home/*/.bashrc /home/*/.profile 2>/dev/null

3. 查 .env 与云凭据文件

find / -type f \( -name ".env" -o -name "credentials" -o -name "application_default_credentials.json" \) 2>/dev/null
grep -RInE 'AWS_ACCESS_KEY_ID|AWS_SECRET_ACCESS_KEY|GOOGLE_APPLICATION_CREDENTIALS|AZURE_' /opt /srv /var/www /home 2>/dev/null

4. 查 PATH 中是否有用户可写目录

echo "$PATH" | tr ':' '\n'
for p in $(echo "$PATH" | tr ':' ' '); do ls -ld "$p" 2>/dev/null; done

5. 查 pkexec / GCONV_PATH 利用痕迹

grep -RInE 'GCONV_PATH|pkexec' /root/.bash_history /home/*/.bash_history /var/log/* 2>/dev/null
find /tmp /var/tmp /dev/shm -type d -name 'GCONV_PATH=*' 2>/dev/null

0x08 一条现场可执行的排查流程

如果你怀疑环境变量已经被攻击者利用，建议按下面顺序执行：

  1. 先查机器级、用户级环境变量的当前值
  2. 再查持久化配置文件或注册表历史值
  3. 再找时间窗内是否有 .env、云密钥文件、开发配置暴露
  4. 再判断这些变量是否影响了执行路径、加载路径或云访问
  5. 最后再关联到后续 DLL 劫持、云 API 调用、提权或外传

0x09 三个最容易被忽略的落点

1. .env 不是“代码文件”，但价值极高

它常常比样本本身更重要，因为里面直接是可复用的认证材料。

2. PATH 劫持不一定需要管理员权限

只要攻击者能控制搜索顺序里的可写目录，就可能把合法程序导进恶意 DLL。

3. 临时环境变量也值得调查

有些利用并不会永久修改配置，而是在一次命令执行中临时注入环境变量。历史命令和进程命令行因此非常关键。

0x0A 建议的交付结构

环境变量事件适合整理为如下表格：

时间证据源事件关联对象结论
09:01:14文件检查暴露 .envWeb 根目录敏感材料泄露
09:05:33注册表 / 配置修改 Path / Windir用户环境变量存在执行链污染
09:07:41进程 / 历史命令调用高权限程序异常环境变量上下文提权/劫持链成立
09:12:20云审计 / 网络异常访问云资源IAM / Bucket凭据已被复用

0x0B 总结

环境变量检查 在 0x03 阶段，真正有价值的不是列出当前变量值，而是要继续回答：

  • 变量里有没有敏感材料
  • 变量有没有污染执行路径
  • 变量有没有被用于一次性提权或持久劫持
  • 变量变化和后续云访问、DLL 劫持、木马执行是否闭环

当你把 .env、PATH、Windir/SystemRoot、GCONV_PATH 这些看似零散的问题放进同一个执行链视角下，它们就不再只是“配置异常”，而会变成非常具体、非常实战的攻击证据。