威胁情报动态：Ivanti Connect Secure 漏洞链后的授权核查、日志狩猎与边界修复

背景

近期针对 SSL VPN、零信任网关等边界设备的攻击活动仍在持续。公开事件中，Ivanti Connect Secure 的 CVE-2023-46805 与 CVE-2024-21887 经常被组合利用：前者涉及身份验证绕过，后者涉及命令注入。攻击者一旦控制边界设备，通常会窃取会话信息、修改组件文件，并借助设备到内网的既有信任继续活动。

这类事件的难点不只是确认补丁版本。边界设备可能已经遭到持久化，单纯升级并不能证明环境干净。本文给出一套适用于授权渗透测试和应急核查的流程，重点覆盖暴露面确认、安全验证、日志关联、权限边界检查和修复闭环，不提供破坏性利用方法。

以下操作仅适用于自有资产或已取得书面授权的测试环境。生产设备执行完整性检查、重置或抓包前，应先确认业务影响和取证要求。

问题定位：先确认资产与版本，不直接做漏洞利用

第一步是从资产侧确认设备，而不是仅依赖公网扫描结果。建议交叉核对域名解析、负载均衡配置、证书指纹、CMDB 和厂商管理平台，避免漏掉灾备节点或历史地址。

在授权范围内，可以先做低影响的 TLS 和 HTTP 指纹采集。不要根据单个响应头直接判定存在漏洞，最终结论应以设备版本、厂商公告和完整性检查结果为准。

#!/usr/bin/env bash
set -euo pipefail
HOST="vpn.example.org"
OUT="./evidence/${HOST}"
mkdir -p "$OUT"

# 保存解析结果和采集时间，便于后续审计
{
  date -u +'%Y-%m-%dT%H:%M:%SZ'
  getent ahosts "$HOST"
} > "$OUT/asset.txt"

# 仅采集证书，不发送漏洞载荷
openssl s_client -connect "${HOST}:443" -servername "$HOST" \
  -showcerts < /dev/null 2> "$OUT/tls.stderr" \
  | openssl x509 -noout -fingerprint -sha256 -serial -issuer -subject -dates \
  > "$OUT/certificate.txt"

# 记录基础响应头；限制超时和响应体大小
curl --silent --show-error --insecure \
  --connect-timeout 5 --max-time 10 --max-filesize 1048576 \
  --dump-header "$OUT/headers.txt" --output /dev/null \
  "

sha256sum "$OUT"/* > "$OUT/SHA256SUMS"

技术分析：漏洞链后的真实风险

身份验证绕过与命令注入组合后，风险不止是设备被执行一次命令。边界网关通常同时持有用户身份、活动会话、内网路由和认证系统连接信息，因此需要沿以下链路核查：

• 入口控制：互联网是否能够直接访问管理面、调试接口或不必要的 API。
• 身份与会话：是否出现异常会话复用、非常用来源登录、同一会话跨地域跳变。
• 设备完整性：关键组件、Web 文件、启动项和计划任务是否被修改。
• 内网访问：设备地址是否异常连接域控、虚拟化平台、文件服务器或运维网段。
• 日志可信度：本地日志是否缺失、时间跳变或被清理，外部日志平台是否保留副本。

需要特别注意“已修补但此前可能失陷”的情况。补丁只能关闭已知入口，无法自动撤销被窃取的凭据、会话令牌和攻击者已建立的内网访问能力。

操作步骤一：执行厂商完整性检查并保全结果

优先使用厂商提供的完整性检查工具，记录工具版本、执行时间、设备序列号和输出文件哈希。若工具报告异常，不应立即删除文件或重启设备；先保存日志、配置、告警截图和必要的流量证据，再按组织流程隔离。

完整性检查也存在局限：已知检查项通过，只能说明没有命中其覆盖范围，不能替代网络侧和身份侧的关联分析。若厂商建议执行出厂重置、恢复可信镜像或密钥轮换，应严格按公告顺序处理。

操作步骤二：从反向代理和 SIEM 中检索异常请求

如果设备前方部署了 WAF、负载均衡或反向代理，可先围绕少见路径、高风险方法、异常状态码和响应体积建立时间线。不要只搜索公开 IOC；攻击者很容易改变路径、参数和 User-Agent。

# Splunk 示例：按实际索引和字段名调整
index=edge sourcetype IN (nginx:access, waf:http, vpn:audit)
earliest=-30d
| eval uri=coalesce(uri_path, url, request_uri)
| eval src=coalesce(src_ip, client_ip, ip)
| where method IN ("POST","PUT","PATCH")
    OR like(uri,"%/api/%")
    OR like(uri,"%/admin%")
| stats count min(_time) AS first_seen max(_time) AS last_seen
        values(status) AS status values(user_agent) AS ua
        sum(bytes_out) AS bytes_out by src, host, method, uri
| where count < 3 OR bytes_out > 5000000
| convert ctime(first_seen) ctime(last_seen)
| sort - last_seen

上面的查询用于缩小调查范围，并不直接判定恶意。需要继续核对来源 ASN、账号、设备会话 ID、请求前后的认证事件，以及该来源是否属于已知运维出口。

操作步骤三：核查会话与身份异常

边界设备失陷后，应重点检查活动会话，而不是只看登录成功记录。建议将 VPN 会话日志与身份提供商、MFA、EDR 和 DHCP 日志关联，至少检查以下模式：

• 同一账号在短时间内从不同国家、ASN 或设备指纹建立会话。
• MFA 记录缺失，但 VPN 侧出现成功认证或会话恢复。
• 离职、停用或服务账号建立交互式远程接入。
• 会话持续时间明显高于基线，或在维护窗口外反复重连。
• VPN 分配地址访问与岗位无关的管理端口，如 445、3389、5985、5986、22。

# Microsoft Sentinel / Log Analytics 示例，字段需按数据源适配
let window = 15m;
SigninLogs
| where TimeGenerated > ago(30d)
| where ResultType == 0
| project UserPrincipalName, LoginTime=TimeGenerated,
          LoginIP=IPAddress, Country=tostring(LocationDetails.countryOrRegion)
| join kind=inner (
    CommonSecurityLog
    | where TimeGenerated > ago(30d)
    | where DeviceProduct has_any ("VPN", "Connect Secure")
    | project UserPrincipalName=SourceUserName,
              VpnTime=TimeGenerated, VpnIP=SourceIP,
              DestinationIP, DestinationPort
) on UserPrincipalName
| where abs(datetime_diff('minute', LoginTime, VpnTime)) <= 15
| where LoginIP != VpnIP
| summarize Destinations=make_set(strcat(DestinationIP, ":", DestinationPort), 100),
            LoginIPs=make_set(LoginIP), VpnIPs=make_set(VpnIP)
            by UserPrincipalName, bin(VpnTime, window)

操作步骤四：检查设备到内网的横向链路

在防火墙、NDR 或 NetFlow 中，以 VPN 设备的管理地址、隧道地址和服务地址为源进行回溯。正常情况下，设备到内网的访问目标应相对固定，例如 DNS、NTP、LDAP、RADIUS、日志服务器和更新源。若设备直接访问终端网段或高价值管理端口，应逐条确认业务依据。

建议将调查结果整理成“源地址、目标地址、端口、首次出现、最后出现、流量大小、对应账号、处置结论”的表格。若只能获得流量元数据，也可通过首次出现时间和访问目标偏离程度发现异常。

日志留痕与证据保全

调查期间不要只导出截图。原始日志应保留时区、字段结构和采集时间，并计算哈希。设备时间可能被修改，因此需要同时记录 SIEM 接收时间、上游代理时间和身份系统时间。

# 对导出的日志建立清单并计算哈希
CASE="IR-2025-EDGE-001"
find "./${CASE}" -type f -print0 \
  | sort -z \
  | xargs -0 sha256sum \
  > "./${CASE}/evidence.sha256"

# 校验时使用
sha256sum -c "./${CASE}/evidence.sha256"

若需要采集设备内存、磁盘镜像或敏感配置，应使用组织批准的取证流程，并限制证据访问权限。配置文件可能包含共享密钥、证书私钥和目录服务凭据，不适合直接上传到普通工单或聊天工具。

风险判断

修复建议

• 严格依据厂商公告执行临时缓解、补丁升级和恢复步骤；集群中的所有节点都要核查。
• 若存在失陷迹象，优先恢复可信镜像或按厂商要求重置，不要只删除可疑文件。
• 吊销现有 VPN 会话，轮换本地管理员、LDAP/RADIUS 绑定账号、API 密钥和设备证书；轮换前先确认依赖关系。
• 将管理面迁移到独立管理网，仅允许堡垒机或固定运维出口访问，禁止互联网直连。
• 限制 VPN 设备到内网的出站访问，只放行 DNS、NTP、认证、日志等必要目标和端口。
• 将认证、管理员操作、配置变更和系统日志实时发送到外部平台，并设置不可由设备管理员直接删除的保留策略。
• 建立补丁后的复测项：版本确认、管理面访问控制、异常会话清理、凭据轮换验证和日志告警演练。

总结

边界设备漏洞事件不能以“补丁安装成功”作为结束条件。更可靠的闭环应包括资产确认、低影响验证、设备完整性检查、身份与网络日志关联、凭据和会话处置，以及权限边界收缩。对于日志不完整的环境，应明确记录证据缺口，避免把“未发现”误写成“未发生”。

这类事件里，“升级到修复版本”只是第一步。Ivanti Connect Secure 一旦出现漏洞链利用迹象，应按设备身份、会话材料和配置均可能失陷处理，不能只封禁源 IP。

建议按下面顺序做：

1. 先隔离并保全证据。限制管理面访问，导出系统配置、事件日志、管理员审计日志、认证日志及完整性检查结果；同时保存上游 WAF、DNS、NetFlow 和认证平台日志。不要在取证前直接恢复出厂，否则会丢失关键时间线。
2. 做两层授权核查。一层检查设备本地管理员、认证服务器、Realm/Role、访问策略和新建证书；另一层检查漏洞利用后得到的 VPN 会话，包括异常长会话、同一账号跨地域并发、非工作时段登录，以及未经过正常 MFA 流程却建立成功的会话。
3. 主动吊销信任材料。终止全部活动会话，轮换本地管理员、LDAP/AD 绑定账号、RADIUS/TACACS 密钥、API 凭据及设备证书私钥。若使用 SAML，还要核查并视情况轮换签名证书，同时撤销 IdP 侧相关会话；仅修改用户密码通常不足以让既有会话失效。

日志狩猎不要只匹配厂商 IOC。建议先统一设备、IdP、AD 和边界日志的时区，再围绕“认证成功—会话建立—内网访问”做关联。下面是一个可直接改字段名的 Splunk 思路，用于找同一用户短时间内来源地址快速变化：

index IN ("ivanti", "idp", "vpn")
(action="login_success" OR event_type="session_start")
| eval user=lower(coalesce(user, username, account))
| eval src=coalesce(src_ip, client_ip, source_ip)
| bin _time span=30m
| stats dc(src) AS src_count values(src) AS src_list
        values(user_agent) AS ua_list count BY user, _time
| where src_count >= 3
| sort - src_count

如果有防火墙或 NetFlow，可进一步检查 VPN 地址池到管理网段的异常横向流量，尤其是 LDAP、SMB、RDP、WinRM、SSH 和虚拟化管理端口：

index=network src_zone=vpn
(dest_port IN (22,88,135,389,445,636,3389,5985,5986,8006, vcenter_port))
| stats count dc(dest_ip) AS dst_count
        values(dest_ip) AS dst_list
        values(dest_port) AS ports BY src_ip, user
| where dst_count > 10 OR count > 100
| sort - dst_count

设备侧完整性检查建议同时执行外部与内置检查能力，并保留原始报告。需要注意：检查结果为“正常”不能单独证明未失陷；如果攻击发生在日志留存窗口之外、日志被清理，或者植入点不在检查覆盖范围内，仍可能漏报。重点关注这些变化：

• 未记录在变更单中的管理员、认证源、Realm、Role、ACL 和路由变化；
• 新出现或被替换的证书、私钥、SAML 元数据及受信任 CA；
• 异常计划任务、启动项、Web 资源修改，以及系统分区完整性告警；
• 日志中断、时间回拨、日志级别被降低，或审计记录与配置变更无法对应；
• 设备主动连接陌生公网地址，特别是利用时间之后持续存在的低频出站连接。

边界修复方面，如果已经确认利用成功、完整性检查异常，或者无法解释配置与日志缺口，稳妥做法是：使用厂商提供的干净镜像执行恢复出厂或重建，升级到明确修复该漏洞链的版本，再从利用发生前且经过人工审查的配置恢复。不要把失陷设备当前配置原样导回新系统，至少应先比较管理员、认证、授权、证书和网络策略差异。

最后，建议把事件时间线延伸到 VPN 后端：查询对应账号在 AD 的 Kerberos/NTLM 登录、主机 EDR、文件访问和特权组变更。边界设备被打穿后，真正需要确认的是攻击者是否已经拿到持久凭据或进入内网，而不是设备页面当前是否恢复正常。