国际威胁情报动态：CVE-2025-0282 边界 VPN 在野利用后的授权核查与日志取证

背景

2025 年初披露的 CVE-2025-0282 是 Ivanti Connect Secure 等边界设备中的栈缓冲区溢出漏洞。公开威胁情报显示，该漏洞在补丁发布前已被用于真实攻击，部分事件随后出现 Web Shell、凭据窃取及 SPAWN 系列驻留组件。此类事件的重点不只是“版本是否已升级”，而是确认补丁前是否已经发生入侵。

本文以获得授权的企业自查为前提，给出一套适用于边界 VPN 设备的排查链路：确认暴露面、执行完整性检查、关联外部日志、核查内网横向行为，最后完成凭据轮换和设备重建。不会提供漏洞利用代码。

已安装补丁只能阻止后续利用，不能清除补丁前建立的持久化。若完整性检查异常，应按已失陷设备处理，而不是简单重启后继续上线。

问题定位：先确认资产和时间窗口

CVE-2025-0282 影响范围与修复版本应以厂商公告为准。Ivanti Connect Secure 22.7R2.5 及更早版本属于重点核查对象，22.7R2.6 提供了对应修复。排查时至少收集以下信息：

• 设备型号、软件版本、补丁安装时间和最近一次重启时间。
• 公网管理面、用户 VPN 入口及集群节点的 IP、域名和 NAT 映射。
• 2024 年 12 月中旬至完成修复期间的 VPN、认证、管理和防火墙日志。
• 设备内置完整性检查工具 ICT 的历史结果，以及厂商提供的外部 ICT 检查结果。
• 与 VPN 对接的 LDAP、RADIUS、SAML、AD、堡垒机及 EDR 日志。

若设备处于集群中，必须逐节点确认版本和完整性状态。只检查虚拟 IP 或主节点，容易遗漏已被下线但仍可访问内网的节点。

技术分析：攻击链应如何拆分

边界设备通常缺少完整 EDR 能力，而且攻击者可能修改本机日志。因此，判断是否失陷时应优先相信设备外部的数据源，包括集中 Syslog、上游防火墙、身份提供商和内网终端日志。

操作步骤一：执行完整性检查并保全证据

首先按照厂商文档运行设备内置 ICT，并使用厂商提供的外部 ICT 再检查一次。外部检查的价值在于减少设备本地组件被篡改后产生假阴性的风险。发现异常后，不要立即恢复出厂设置，应先完成以下动作：

• 从负载均衡或公网 NAT 中隔离异常节点，但保留管理侧取证通道。
• 导出系统配置、事件日志、审计日志、支持包和 ICT 报告。
• 记录导出文件的获取时间、操作者和 SHA-256，建立基本证据链。
• 保存上游设备日志，避免短保留周期覆盖关键时间段。

mkdir -p case-2025-0282/evidence
cp exported/* case-2025-0282/evidence/
find case-2025-0282/evidence -type f -print0 \
  | sort -z \
  | xargs -0 sha256sum \
  > case-2025-0282/SHA256SUMS

date -u +'%Y-%m-%dT%H:%M:%SZ' > case-2025-0282/collection-time.txt
chmod -R a-w case-2025-0282/evidence case-2025-0282/SHA256SUMS

不要在未确认厂商支持边界前直接登录设备底层系统执行命令。部分 VPN appliance 的底层 Shell 不属于受支持接口，误操作既可能破坏证据，也可能导致设备不可用。

操作步骤二：从集中日志重建异常会话

对导出的 Syslog 先做时间规范化，再围绕管理登录、认证失败、会话建立、配置变更、重启和完整性告警检索。下面的命令适用于已经汇总为文本的日志，字段名称需要按实际格式调整：

# 提取重点事件并保留上下文
zgrep -Eai 'integrity|admin|login|authentication|session|config|restart|reboot|error' \
  vpn-syslog-2024-12*.gz vpn-syslog-2025-01*.gz \
  > vpn-key-events.log

# 汇总日志中的 IPv4 地址，快速发现低频来源
awk '{
  while (match($0, /([0-9]{1,3}\.){3}[0-9]{1,3}/)) {
    print substr($0, RSTART, RLENGTH)
    $0=substr($0, RSTART+RLENGTH)
  }
}' vpn-key-events.log | sort | uniq -c | sort -n > ip-frequency.txt

# 检查补丁前后是否存在异常重启、配置变化或 ICT 告警
grep -Eai 'integrity|restart|reboot|configuration changed|upgrade' \
  vpn-key-events.log

IP 低频不等于恶意，高频也不等于正常。需要结合 ASN、地理位置、账号历史、登录时间和后续内网访问判断。尤其关注以下组合：

• 某账号从未出现过的国家或云服务 ASN 登录，随后立即访问管理网段。
• 同一来源在多个账号之间切换，成功登录前存在密集失败记录。
• 服务账号通过 VPN 建立交互式会话。
• 设备出现无变更单对应的重启、配置导出、管理员创建或认证策略修改。
• 登录成功后没有典型用户流量，却持续探测 LDAP、SMB、RDP、WinRM 或 SSH。

操作步骤三：关联内网横向链路

边界设备失陷后的主要风险是攻击者继承其网络位置。应以 VPN 地址池、设备管理地址和异常账号为中心，查询内网防火墙或 Zeek 连接日志。以下示例统计 VPN 地址段对敏感端口的访问：

zcat /data/zeek/conn.2025-01-*.log.gz \
  | zeek-cut ts id.orig_h id.resp_h id.resp_p proto duration orig_bytes resp_bytes \
  | awk '$2 ~ /^10\.66\./ && $4 ~ /^(22|88|389|445|636|3389|5985|5986|8006|9443)$/ {print}' \
  > vpn-sensitive-connections.tsv

# 按源地址、目标地址和端口聚合
awk '{k=$2"\t"$3"\t"$4; n[k]++; out[k]+=$7; inb[k]+=$8}
END {for (k in n) print n[k], out[k], inb[k], k}' \
  vpn-sensitive-connections.tsv | sort -nr > vpn-sensitive-summary.tsv

如果没有 Zeek，可在防火墙平台上使用同样的筛选逻辑：源地址属于 VPN 地址池或 appliance 管理地址，目标端口属于身份、文件共享、远程管理及虚拟化管理服务。对命中记录继续核查目标主机的 EDR 进程树和系统日志。

Windows 侧建议重点关联 4624、4625、4648、4672、4688、4768、4769、4776 和 7045 事件。需要注意 4624 的源地址有时会因 NAT 或代理显示为 VPN 设备地址，因此还要结合 VPN 会话中的用户名和分配地址。

关键判断：哪些情况应直接按失陷处置

• 内置或外部 ICT 报告异常，且无法由已知升级操作解释。
• 补丁前存在异常管理员活动、配置变化或不明重启。
• VPN 设备向互联网建立无法解释的主动连接。
• 设备或 VPN 地址池访问了与业务无关的域控、备份、虚拟化或安全管理系统。
• 同一时间窗口出现异常 SAML、LDAP、RADIUS 认证或高权限账号使用。
• 厂商或事件响应团队确认存在 Web Shell、SPAWN 系列组件或其他持久化迹象。

风险与修复建议

确认或高度怀疑失陷后，推荐采用“隔离、重建、轮换、验证”的顺序：

• 隔离：从公网入口和内网路由中移除异常节点，临时使用已验证节点或替代接入方案。
• 重建：按厂商流程执行恢复出厂或重新部署，不要只删除可疑文件。升级到已修复版本后重新导入经过审计的最小配置。
• 轮换：更换本地管理员、LDAP 绑定账号、RADIUS 共享密钥、API 密钥、设备证书私钥及可能经设备处理的高权限账号凭据。
• 身份处置：吊销活动会话和刷新令牌，检查 SAML 签名证书、IdP 应用配置及异常 MFA 注册。
• 网络收敛：限制 VPN 地址池直接访问域控、备份、虚拟化和安全平台，改由堡垒机或应用级代理转发。
• 持续监测：至少覆盖已知最早利用时间至重建完成后的观察期，并将设备日志实时发送到不可由 appliance 管理员删除的集中平台。

管理面应只允许从专用管理网或堡垒机访问，并启用独立的多因素认证。对于必须暴露公网的用户入口，上游设备应保留完整连接元数据；TLS 解密是否启用需根据合规要求决定，但不能以加密为由放弃流量基线和出口监测。

验证修复是否真正完成

修复完成后不能只验证页面可访问。建议进行以下闭环检查：

• 逐节点确认版本、补丁级别、启动时间和 ICT 结果。
• 确认旧节点、公网 NAT、DNS 记录和负载均衡成员已下线。
• 使用测试账号完成一次 VPN 登录，验证 MFA、地址分配和最小访问策略。
• 检查新节点是否仍向旧的未知公网地址发起 DNS 或 TCP 连接。
• 确认所有高风险密钥和凭据均在重建后生成，而非从旧配置原样恢复。
• 对补丁前后日志做时间线复盘，确保异常内网目标已逐台核查。

总结

CVE-2025-0282 这类边界设备在野利用事件，不能用“升级完成”作为处置终点。更可靠的做法是把设备视为潜在跳板，通过 ICT、集中日志、身份系统和内网流量重建完整链路。只要出现完整性异常或无法解释的管理活动，就应优先选择可信介质重建，并同步轮换设备可接触到的凭据和密钥。边界设备本地证据有限，提前建设外部日志留存和网络分区，往往比事后增加扫描工具更有效。

这类事件不要只做“升级后扫一遍”。CVE-2025-0282 是未认证远程代码执行，攻击发生在 VPN 登录之前，因此没有异常登录记录并不能排除失陷。建议把补丁处置和失陷核查分开进行。

1. 先确认暴露窗口

• 确认设备型号、当前及历史版本，核对是否已升级到厂商针对该型号发布的修复版本。
• 从防火墙、负载均衡、NetFlow/CDN 日志还原公网暴露时间，调查起点至少回溯到 2024 年 12 月；如果日志保留允许，建议再向前扩展。
• 保存升级前后的配置备份、系统日志、管理员审计日志、VPN 用户日志和 Integrity Checker 结果。注意配置备份不能替代取证镜像。

2. Integrity Checker 的结果要这样看

先运行外部 Integrity Checker，再按 Ivanti 的流程运行设备内置检查。只要出现文件不一致、未知修改或检查失败，都按已失陷处理。即使检查结果正常，也只能说明当前未发现已知完整性异常，不能证明设备此前没有被入侵后清理痕迹。

不要直接在生产设备上反复执行未经厂商确认的 shell 命令，这可能改变时间戳和证据。优先通过管理界面导出日志、系统快照和支持包，并记录文件哈希：

sha256sum ivanti-support-package.tgz exported-logs.tgz config-backup.cfg
stat -c '%n %s %y' ivanti-support-package.tgz exported-logs.tgz config-backup.cfg

3. 日志核查不要只盯登录成功

重点关联以下几类事件：

• 未认证请求后紧接着出现设备重启、服务崩溃、核心转储或异常高 CPU。
• 管理员账号新增、权限提升、认证服务器或 SAML 配置变更。
• 日志转发被关闭、日志级别降低、NTP/DNS/代理配置被修改。
• 来源 IP 从未完成 VPN 登录，却在随后访问内部管理面、LDAP、RDP、SMB、SSH 或虚拟化平台。
• 同一账号短时间内从不相关 ASN、国家或设备指纹登录，尤其是管理员和服务账号。
• 补丁前后出现无法解释的日志空洞；这通常比单条异常请求更值得关注。

导出为文本或 JSON 后，可以先做时间线和高频来源筛选。例如：

# 按时间提取安全相关事件，字段名需按实际导出格式调整
jq -r '
  select(
    (.event // "" | test("admin|config|restart|crash|integrity|auth"; "i")) or
    (.message // "" | test("administrator|configuration|reboot|core|failed"; "i"))
  ) |
  [.timestamp, .src_ip, .user, .event, .message] | @tsv
' appliance-events.json | sort > suspicious-timeline.tsv

# 统计公网来源；排除已知监控、办公出口后再分析
awk '{print $1}' vpn-access.log | sort | uniq -c | sort -nr | head -100

如果日志已进入 Splunk，可先从“无登录但随后访问内网”的链路入手：

index=* earliest=-120d
(
  sourcetype=ivanti*
  OR dest IN ("vpn.example.com","vpn-management.example.com")
)
| eval src=coalesce(src_ip,src)
| stats
    values(action) AS actions
    values(user) AS users
    values(uri_path) AS paths
    min(_time) AS first_seen
    max(_time) AS last_seen
    count
  by src
| where count > 20
| convert ctime(first_seen) ctime(last_seen)

4. 授权核查要覆盖设备之外

攻击者获得设备级执行能力后，可能读取缓存凭据、会话令牌、LDAP 绑定密码、RADIUS/TACACS 密钥及 SAML 相关材料。建议逐项核对：

• 本地管理员、只读管理员及 API 账号是否存在异常新增、解锁或权限变化。
• LDAP 绑定账号是否拥有超出目录查询所需的权限。
• RADIUS/TACACS、SNMP、日志转发、备份和自动化账号密钥是否需要轮换。
• SAML IdP/SP 配置、证书、签名算法、回调地址和元数据是否被修改。
• VPN 地址池到内网的 ACL 是否过宽，尤其是对域控、备份系统、虚拟化平台和运维网段的访问。
• 现存 VPN 会话是否全部失效，已有令牌是否仍可复用。

凭据轮换顺序建议是：先隔离或替换设备，再吊销会话和令牌，随后轮换设备管理员、目录绑定账号、共享密钥及相关证书。若先改密码而设备仍受控，新凭据可能再次泄露。

5. 出现任一异常时，不建议原地“清理”

发现完整性异常、可疑配置修改、日志缺口或横向移动证据时，应按厂商建议执行工厂重置并使用可信镜像重建，只恢复经过人工审查的必要配置。重建后重新生成设备证书和密钥，不要直接恢复包含旧密钥、未知管理员或可疑脚本的完整备份。

最后还要在下游系统验证是否发生横向移动：查询域控登录事件、EDR、DNS、代理、RDP/SMB/SSH 和虚拟化管理日志，并以 VPN 设备的公网访问时间为锚点建立统一时间线。只在边界设备上得到“未发现异常”，不足以结束此次核查。