威胁情报复盘：Ivanti VPN 零日利用事件中的权限边界、日志核查与恢复要点

背景：从边界设备漏洞到内网入口

2024 年 1 月，Ivanti Connect Secure、Policy Secure 披露的 CVE-2023-46805 与 CVE-2024-21887 引发持续关注：前者涉及身份验证绕过，后者涉及命令注入，两者组合后可能让未认证攻击者在受影响设备上执行命令。Mandiant 当时披露了关联 UNC5221 的实际入侵活动，美国 CISA 随后发布紧急指令 ED 24-01，并在 1 月 31 日补充处置要求。

这不是一篇实时漏洞通告，而是对该次已公开利用事件的技术复盘。重点是：在授权排查中，如何把外部威胁情报转成可执行的日志核查、权限边界检查和恢复动作，而不是只确认“版本是否打过补丁”。历史通告中的版本和缓解措施不能直接替代当前厂商支持矩阵。

具体场景与问题定位

假设某企业将 Connect Secure 部署在互联网边界，后端连接 AD、RADIUS 和多个内网业务网段。设备已经安装修复版本，但安全团队需要判断：修复前是否发生利用，设备是否留下持久化修改，以及攻击者是否借助 VPN 身份进入内网。

• 资产侧：确认产品、版本、构建号、外网暴露时间，以及补丁和临时缓解措施的实际生效时间。
• 身份侧：梳理设备保存或使用的目录服务绑定账户、RADIUS 共享密钥、管理员账户和证书私钥。
• 网络侧：列出 VPN 地址池、管理接口可达范围、设备主动访问内网的策略，以及出口放行范围。
• 证据侧：收集设备诊断包、完整性检查结果、远程日志、外围防火墙流量、DNS 查询与身份认证记录。

不要只从披露日期开始搜索。调查窗口应覆盖可能的暴露期，并考虑日志轮转造成的空白。资产升级时间也不能简单等同于风险结束时间：补丁关闭漏洞，不会自动清除此前植入的文件或撤销已泄露凭据。

技术分析：真正失守的是哪些边界

这组漏洞的重要性在于，原本受身份认证保护的设备功能可能被绕过，命令注入随后把应用接口问题扩大为设备执行权限问题。获得设备侧执行能力后，攻击者可能接触配置、认证材料或流经设备的信息，并尝试篡改组件维持访问。

VPN 会话本身也不是安全边界的终点。即使未发现明确恶意文件，只要存在可疑登录，也应继续检查对应 VPN 地址访问了哪些内网系统。例如，同一账户新建 VPN 会话后立即访问域控制器、文件服务器或运维入口，比单独一条异地登录更值得优先调查。

完整性检查通过，只能说明在该工具、该版本与该检查范围内未发现异常，不能独立证明设备未被入侵。本地日志同样可能不完整，应与设备之外的证据交叉验证。

操作步骤：先固化证据，再缩小范围

• 在不扩大暴露面的前提下，优先从受支持的管理界面导出日志和诊断材料，记录设备时间、时区及其与标准时间的偏差。
• 同步保全远程 Syslog、外围防火墙、DNS、身份提供方日志，避免只保留设备本地副本。
• 使用厂商适配当前产品和版本的完整性检查工具，并保存工具版本、执行时间和原始结果。
• 将请求异常、管理变更、VPN 登录和设备出站连接放到同一条时间线上，核查是否存在相互支持的证据。
• 如已出现明确失陷迹象，应按事件响应流程隔离并取证，不要继续用生产设备执行漏洞复现。

命令示例：离线筛查导出的访问日志

下面的示例只处理已经合法导出的明文访问日志，不向目标发送请求。它寻找 API 请求附近的路径穿越特征，用于初步缩小人工复核范围，不是这两个 CVE 的完整检测规则。执行前应将压缩日志解压到独立目录，并确认导出材料确实包含请求路径字段。

# 原始导出目录设为只读，派生结果放到另一个目录
mkdir -p ./case-output
find ./exported-logs -type f -print0 | sort -z | \
  xargs -0 -r sha256sum > ./case-output/evidence.sha256

# 示例针对常见的逐行文本访问日志；不适用于二进制诊断文件
python3 - <<'PY' > ./case-output/path-review.tsv
from pathlib import Path
from urllib.parse import unquote

root = Path('./exported-logs/access')
if not root.is_dir():
    raise SystemExit('请先确认 exported-logs/access 为访问日志目录')

print('file\tline\treason')
for path in sorted(root.rglob('*')):
    if not path.is_file():
        continue
    with path.open('r', encoding='utf-8', errors='replace') as stream:
        for number, raw in enumerate(stream, 1):
            normalized = raw.lower()
            # 最多解码两次，仅用于候选筛查，不模拟设备路由行为
            for _ in range(2):
                decoded = unquote(normalized)
                if decoded == normalized:
                    break
                normalized = decoded
            if '/api/' in normalized and '/../' in normalized:
                print(f'{path}\t{number}\tapi-path-traversal-candidate')
PY

脚本只输出文件名、行号和原因，避免把可能包含会话标识或敏感参数的整行日志复制进普通工单。复核时应查看原始证据，而不是仅查看解码后的文本。整行匹配可能命中查询参数、请求头或扫描器探测，需要结合日志格式进一步解析。

命中后重点确认请求时间、源地址、请求路径、状态码、响应大小及相邻事件。HTTP 200 不等于利用成功，未命中也不能排除利用；设备内部服务请求不一定完整出现在外围访问日志中。若存在反向代理，只信任已知代理链写入的客户端地址字段，不要直接把客户端可伪造的 X-Forwarded-For 当作真实来源。

从入口异常追到内网活动

建议按“外部来源—设备事件—VPN 会话—内网目的”建立关联表，至少保留时间、账户、会话标识、分配地址、目的地址和动作结果。特别注意 VPN 地址池复用：不能把一天内使用过同一个地址的流量全部归到一个账户，必须按会话起止时间切分。

• 设备侧：检查新增管理员、认证服务器修改、日志转发关闭、配置导出和异常重启。
• 身份侧：检查特权账户的新来源登录、异常 MFA 事件，以及目录服务账户是否出现在不符合预期的主机上。
• 网络侧：检查设备自身异常出站连接，以及 VPN 会话访问管理端口、文件共享或远程管理服务的行为。
• 终端侧：围绕对应时间和账户查询 EDR、Windows 安全日志或 Linux 认证日志，确认是否发生远程登录和后续执行。

VPN 使用本地认证、RADIUS、LDAP 或联合身份时，下游可见事件并不相同。不要假设每一次 VPN 登录都会在域控制器留下同一种事件，也不要因为目录侧没有记录就结束调查。

风险与修复建议

• 未发现失陷证据：按当前厂商公告完成升级和必要缓解，收紧管理面与 VPN 到内网的访问范围，并保留后续监测窗口。
• 确认或高度怀疑设备失陷：按厂商与事件响应指引评估重置、重建和恢复，不把“原地升级成功”作为恢复可信状态的唯一依据。
• 处理关联凭据：根据实际暴露范围轮换管理员密码、目录绑定凭据及共享密钥，评估证书私钥是否需要替换，并撤销相关活动会话。
• 调整操作顺序：避免在仍不可信的设备上输入新密钥。凭据轮换应与可信恢复及重新接入协调，防止新凭据再次泄露。
• 降低后续影响：VPN 用户默认只获得业务所需访问权限，管理区单独授权；日志实时外送，设备出口按业务需要限制。

总结与公开依据

这次事件最值得保留的经验是：边界设备漏洞的调查单位，不应只有设备版本，还应包含身份材料、会话和内网访问链路。补丁验证解决“入口是否关闭”，完整性检查与跨源日志解决“是否已经进入”，重建与凭据处置才解决“能否重新信任”。

公开依据：Ivanti 关于 CVE-2023-46805、CVE-2024-21887 的安全公告；Mandiant 2024 年 1 月 10 日发布的相关零日利用分析；CISA ED 24-01 及后续补充指引。CISA 指令原文： 。实际处置前应再次核对厂商最新适用版本和恢复要求。

这类事件复盘里，最容易低估的是：Ivanti 设备本身既是入口，也是身份与会话边界。确认存在暴露窗口后，不建议只做“升级补丁 + 查几个 IOC”，应先按设备已失陷处理。

权限边界建议重点核对：

• LDAP/AD 绑定账号是否具备不必要的写权限。正常情况下应为只读查询账号，并限制仅能从 VPN 设备地址访问域控。
• 设备上保存的本地管理员、API 密钥、RADIUS shared secret、SAML/OIDC 配置、客户端证书私钥，均应纳入轮换范围。
• 撤销全部现存 VPN 会话和持久化令牌。仅修改用户密码不一定能使已签发会话立即失效。
• 检查通过 VPN 地址池访问管理网、备份网、虚拟化平台和域控的情况，尤其是“登录成功后无明显横向告警”的账号。

日志核查不要只依赖设备本地记录。攻击者获得设备控制权后，本地日志和完整性结果都可能不可信。应以外部 syslog、IdP、域控、EDR、DNS、代理和防火墙日志做时间线交叉验证，并先校准时区与 NTP 偏差。

可以先从 VPN 地址池反查高价值资产访问：

# 示例：从防火墙导出日志中筛选 VPN 地址池到管理端口的连接
awk '$1 >= "2024-01-01" && $1 <= "2024-02-01"' firewall.log |
grep -E 'src=(10\.20\.(1[0-9]|2[0-9])\.)' |
grep -E 'dport=(22|3389|445|5985|5986|443)'

SIEM 中建议把认证与网络行为关联，而不是只搜已公开 URI：

index=vpn earliest=-30d
| stats min(_time) as firstSeen max(_time) as lastSeen
        values(src_ip) as source values(user_agent) as ua count by user
| join user [
    search index=firewall earliest=-30d src_zone="vpn"
    | stats values(dest_ip) as dest values(dest_port) as port by user
]
| where count > 0

重点看这些异常组合：

• 同一账号短时间出现不可能旅行、异常 ASN，或 User-Agent 明显变化；
• MFA 成功前后没有对应的正常交互记录，却已建立 VPN 会话；
• VPN 地址池首次访问域控、vCenter、备份服务器、代码仓库等资产；
• 服务账号交互式登录、远程服务创建、计划任务、SMB/RDP/WinRM 横向活动；
• 设备对外产生异常 DNS、HTTP 或 TLS 连接，特别是此前未见的目的地址。

完整性检查应同时运行厂商提供的外部与内部检查工具，并保存原始结果、配置导出、版本信息和外部日志。需要注意，检查“通过”只能说明未命中当前检测项，不能排除内存驻留、日志清理或未知持久化。

恢复阶段更稳妥的顺序是：隔离旧设备并保全证据 → 使用可信镜像执行 factory reset/reimage → 升级到已修复版本 → 手工重建最小化配置，避免直接恢复未经审查的整机备份 → 轮换设备可访问的全部凭据与密钥 → 吊销会话 → 分阶段恢复流量并持续监控。若暴露期间设备可访问域控或证书系统，还应扩大到域级凭据、证书签发记录和高权限组变更的核查。

最后建议把“互联网暴露时间、首次异常、隔离时间、凭据轮换完成时间”明确写进复盘。Ivanti 事件里，是否补丁成功通常不是最关键的问题，关键是补丁前攻击者已经获得了哪些权限，以及这些权限是否在重建后仍然有效。