Ivanti Connect Secure 漏洞被用于内网入口后的排查、验证与修复要点

背景

近期国际威胁情报中，边界 VPN、SSL VPN、零信任接入网关仍然是攻击者进入内网的高频入口。以 Ivanti Connect Secure / Policy Secure 相关漏洞链为例，CVE-2023-46805 与 CVE-2024-21887 曾被用于未授权访问与命令注入组合利用，后续还出现过 WebShell、配置窃取、横向移动凭据收集等行为。

这类事件适合放在“新闻动态”板块讨论的原因不是漏洞本身有多新，而是它反映了一个持续趋势：攻击者不再只打 Web 入口，而是优先选择拥有内网身份、路由能力和会话凭据的边界设备。下面内容按授权应急排查和漏洞验证角度展开，不提供利用代码。

适用场景：企业已部署 Ivanti Connect Secure / Policy Secure，或同类 SSL VPN 设备；需要判断是否存在被利用痕迹，并制定修复和加固动作。

问题定位

边界设备被打穿后，常见问题不是单点漏洞，而是以下链路：

• 攻击者通过未授权访问或命令注入获取设备执行能力。
• 读取配置、会话、LDAP/RADIUS/AD 对接信息。
• 植入 WebShell 或修改系统组件，维持访问。
• 利用 VPN 已建立的信任关系访问内网资产。
• 使用合法账号登录，降低告警噪声。

排查时不要只看“是否打了补丁”，还要确认补丁前窗口期内是否发生过异常访问、异常文件变更、异常认证和异常内网连接。

技术分析

从蓝队视角，重点关注三类证据：

• 边界访问日志：异常 URI、异常 User-Agent、来自云主机/VPS 的高频访问、非业务时间段管理路径访问。
• 设备完整性：Web 目录、临时目录、配置目录是否出现异常文件；系统脚本是否被替换。
• 内网侧行为：VPN 分配地址是否访问了不常见端口，例如 445、3389、5985、389、636、1433、3306。

在 Ivanti 这类设备上，厂商提供过 Integrity Checker Tool 一类检测工具。实际应急中，建议将厂商检测结果与网关日志、AD 登录日志、EDR、流量日志交叉验证。单一检测工具不能证明“没有被入侵”。

操作步骤

• 第一步：确认资产范围。列出所有公网可达的 VPN / 远程接入设备，包括备用节点、测试节点、灾备节点。
• 第二步：确认版本与补丁。记录当前版本、补丁时间、是否在漏洞公开后存在暴露窗口。
• 第三步：导出日志。包括访问日志、认证日志、管理员操作日志、系统日志、VPN 会话日志。
• 第四步：检索异常访问。关注漏洞相关路径、异常参数、长时间连接、非正常 HTTP 方法。
• 第五步：检查内网访问。将 VPN 分配地址与防火墙、NDR、EDR 日志关联，确认是否出现横向探测。
• 第六步：处置账号。对漏洞窗口期内登录过 VPN 的账号执行密码重置、MFA 重新绑定、会话吊销。

命令示例

以下示例用于日志侧排查思路，命令需在授权环境中执行。不同设备日志路径不同，实际以导出的 syslog 或 SIEM 字段为准。

# 1. 在导出的 Web 访问日志中检索疑似异常管理路径和高风险请求
# access.log 为示例文件名
grep -Ei "(/api/|/dana/|/admin|/debug|/cgi|/meeting|/users/|;|%3b|cmd=|exec|curl|wget)" access.log \
  | awk '{print $1,$4,$5,$6,$7,$9,$12}' \
  | sort | uniq -c | sort -nr | head -50

# 2. 统计非办公时间访问 VPN 的源 IP
# 假设日志时间格式中包含 [HH:MM:SS]
awk '$4 ~ /\[(00|01|02|03|04|05):/ {print $1,$4,$6,$7,$9}' access.log \
  | sort | uniq -c | sort -nr | head -50

# 3. 统计认证失败与成功异常集中的账号
# auth.log 为示例认证日志
grep -Ei "failed|failure|invalid|success|login" auth.log \
  | awk '{print $1,$2,$3,$NF}' \
  | sort | uniq -c | sort -nr | head -50

# 4. 从防火墙日志中筛选 VPN 地址池访问内网敏感端口
# 示例：VPN 地址池为 10.20.30.0/24，需要按实际环境替换
grep "10.20.30." firewall.log \
  | grep -E "dpt=(445|3389|5985|5986|389|636|1433|3306|22)" \
  | awk '{print $1,$2,$3,$0}' \
  | head -100

关键排查点

日志关联方法

建议建立一条清晰时间线，而不是孤立看某一条告警：

• 漏洞公开时间、厂商补丁时间、企业实际修复时间。
• 可疑公网 IP 首次访问时间。
• 异常 VPN 登录时间。
• VPN 地址池访问内网敏感资产时间。
• AD 中异常登录、账号锁定、权限变更时间。

如果 SIEM 支持查询，可以按“源 IP - VPN 用户 - VPN 分配地址 - 内网目标资产 - 认证事件”做五元关联。很多事件中，真正能确认入侵的是内网侧登录和文件访问痕迹，而不是边界设备上的单条异常请求。

风险与修复建议

• 立即升级：将相关设备升级到厂商修复版本，不建议只依赖临时缓解规则。
• 执行完整性检测：使用厂商工具检查系统完整性，并保留原始报告。
• 重置敏感凭据：包括本地管理员、LDAP 绑定账号、RADIUS 密钥、API Token、备份账号。
• 吊销会话：强制下线所有 VPN 会话，要求重新认证。
• 检查 MFA：确认 MFA 绑定未被篡改，重点检查新增设备、备用邮箱、备用手机号。
• 限制 VPN 权限：不要让 VPN 用户默认全网可达，按业务系统、端口、用户组做最小权限访问。
• 增强日志：将 VPN、AD、EDR、防火墙日志统一送入日志平台，保留不少于 180 天。
• 隔离高风险资产：域控、堡垒机、代码仓库、制品库、数据库不应直接暴露给普通 VPN 地址池。

权限边界建议

这类边界设备事件最大的教训是：VPN 登录不等于可信内网身份。建议将 VPN 地址池作为“不完全可信区”处理：

• VPN 用户访问服务器必须经过堡垒机或零信任代理。
• 禁止 VPN 地址池直接访问域控管理端口。
• 运维账号与办公账号分离，运维账号禁止收邮件和访问互联网。
• 高权限操作必须有二次审批或强 MFA。
• 对 VPN 地址池访问 445、3389、5985、22 做告警基线。

总结

从近期威胁情报看，边界 VPN 设备仍是攻击者进入内网的优先目标。对安全团队来说，重点不是复现漏洞，而是判断是否存在被利用窗口、是否有会话和凭据泄露、是否发生内网横向移动。

建议把这类事件当成“边界失陷可能导致内网暴露”的链路来处理：补丁只是第一步，日志回溯、凭据轮换、权限收敛和内网访问控制才是闭环。