国际威胁情报动态：Ivanti Connect Secure CVE-2025-0282 在野利用后的验证与内网排查

发布于8小时前8小时

背景

2025年1月，Ivanti披露Connect Secure、Policy Secure及Neurons for ZTA网关中的CVE-2025-0282。该漏洞属于未经身份验证的栈缓冲区溢出，已被用于实际攻击。对企业而言，风险不只是VPN入口被控制：边界设备通常可访问LDAP、RADIUS、DNS和内部管理网，攻击者还可能窃取会话、配置及服务账号凭据。

厂商给出的修复基线包括Connect Secure 22.7R2.5、Policy Secure 22.7R1.2和Neurons for ZTA 22.7R2.3。不同型号、分支和生命周期状态存在差异，实际处置时应以设备序列号对应的厂商公告为准。不能只根据登录页特征判断是否受影响，也不建议在生产设备上直接运行公开利用代码。

本次排查的重点应是：确认资产和版本、运行完整性检查、验证管理面暴露情况、关联身份认证日志，并判断是否已经形成“边界设备—身份系统—内网主机”的攻击链。

问题定位

先区分“存在受影响版本”和“已经遭到利用”两个问题。前者可通过资产台账及管理控制台确认，后者需要完整性检查、日志关联和网络侧证据共同判断。

资产侧：型号、版本、补丁级别、设备角色、管理地址、互联网出口地址。
暴露面：443业务入口是否公开，管理接口是否与业务接口复用，是否存在IPv6或备用线路遗漏。
完整性：运行设备内置Integrity Checker Tool；高风险场景同时执行厂商提供的外部完整性检查。
身份侧：检查LDAP、RADIUS、SAML及本地管理员账号是否出现异常认证。
网络侧：检查设备到域控、文件服务器、虚拟化平台及运维网段的非预期连接。

非侵入式资产核验

下面的命令只采集HTTP响应头和TLS证书信息，适合授权范围内的快速盘点，不会触发漏洞。部分设备不会在外部页面暴露准确版本，因此结果只能用于资产关联，不能代替管理后台版本核验。

while IFS= read -r host; do
  printf '\n### %s ###\n' "$host"
  curl -k -sS --connect-timeout 5 --max-time 10 \
    -D - -o /dev/null " | sed -n '1,20p'

  echo | openssl s_client -connect "$host:443" -servername "$host" 2>/dev/null \
    | openssl x509 -noout -subject -issuer -serial -dates -fingerprint -sha256
done < authorized_targets.txt

建议把证书指纹与CMDB、负载均衡配置及防火墙NAT规则比对。如果同一证书出现在未登记地址，往往意味着存在备用节点、灾备节点或历史设备未纳入补丁范围。

日志与完整性排查

应先导出系统日志、管理员审计日志、认证日志、配置备份和支持包，再进行重启、升级或恢复操作。导出文件应计算哈希并只读保存，避免后续无法还原时间线。

mkdir -p evidence
cp -a exported_logs support_bundle evidence/
find evidence -type f -print0 | sort -z | xargs -0 sha256sum > evidence.sha256

# 初筛异常命令、临时目录落地和权限修改痕迹；命中项需要人工复核
LC_ALL=C grep -RInaE \
'(curl|wget|nc[[:space:]]|bash[[:space:]]+-c|python[0-9]*[[:space:]]+-c|/tmp/|chmod[[:space:]]+\+x)' \
 evidence/ > suspicious-lines.txt

# 汇总VPN常见业务路径的来源地址，识别短时间高频访问
zgrep -hE '/dana-na/|/dana-ws/' exported_logs/*.gz 2>/dev/null \
 | awk '{print $1}' | sort | uniq -c | sort -nr | head -50

关键关注点包括：完整性检查失败、未知管理员登录、配置在非变更窗口被修改、日志突然中断、系统时间变化、异常重启，以及设备主动连接不常见的外部地址。单条Web请求或字符串匹配不能直接作为入侵结论，应结合时间、源地址、进程行为和网络流量确认。

内网攻防链路验证

边界设备失陷后，常见链路是获取设备控制权，读取配置或会话信息，借助LDAP、RADIUS或SAML身份进入内网，随后访问域控、运维平台和虚拟化管理面。验证时不需要复现破坏性利用，而应围绕设备可达性和身份使用情况进行检查。

查询防火墙流量，确认VPN设备是否访问过SMB 445、WinRM 5985/5986、RDP 3389、SSH 22或虚拟化管理端口。
在域控检查4624、4625、4768、4769事件，重点关注来源为VPN设备地址、同一账号跨地域登录、服务账号交互式登录。
检查RADIUS和SAML日志中是否存在成功认证但缺少对应VPN会话的记录。
核对设备绑定的LDAP查询账号是否具有写目录、远程登录或本地管理员权限。该账号原则上只应具备目录读取权限。

在Microsoft Sentinel或兼容KQL的数据平台中，可先用以下查询检查来自VPN设备地址的身份活动：

SecurityEvent
| where TimeGenerated > ago(30d)
| where EventID in (4624, 4625, 4768, 4769)
| where IpAddress in ("10.20.30.10", "10.20.30.11")
| summarize Count=count(), Users=make_set(TargetUserName, 50),
            Hosts=make_set(Computer, 50)
            by EventID, IpAddress, bin(TimeGenerated, 30m)
| order by TimeGenerated desc

如果设备到域控的正常业务只有LDAP或Kerberos，而流量日志中出现SMB、RDP或WinRM，应按高优先级调查。还需注意NAT可能导致多个VPN节点共用来源地址，应结合设备日志中的会话ID和用户名关联。

权限边界与处置建议

确认未被利用且完整性检查正常：升级到厂商指定修复版本，重新运行完整性检查，并持续监控至少一个凭据有效周期。
完整性检查失败或已有明确入侵迹象：先隔离设备并保全日志，不应只覆盖安装补丁。按厂商流程执行恢复出厂、重新镜像或替换设备，再导入经过审计的最小化配置。
轮换本地管理员、LDAP/RADIUS绑定账号、API密钥、设备证书私钥及可能经过设备的高权限凭据；同时撤销现存会话和令牌。
将管理接口限制在独立运维网，通过防火墙白名单或堡垒机访问，禁止直接暴露互联网。
限制设备出站流量，只允许访问必要的DNS、NTP、身份服务、日志平台和更新地址。边界设备不应具备任意访问服务器网段的能力。
将VPN认证账号与运维管理员账号分离，对管理员启用抗钓鱼MFA，并禁止服务账号进行交互式登录。
把设备日志实时发送到远端SIEM。仅保存在设备本地的日志，在设备失陷后可信度有限。

总结

CVE-2025-0282这类边界设备漏洞的处置不能停留在“版本升级完成”。有效流程应包含资产核验、完整性检查、证据保全、身份日志关联、内网可达性审计和凭据轮换。若发现完整性异常，应按设备已经失陷处理，通过重建可信状态和收紧权限边界，避免攻击者利用残留会话或服务账号再次进入内网。

6小时前6小时

这类事件里，最容易误判的是“升级后 ICT 通过＝未失陷”。CVE-2025-0282 属于未认证远程代码执行，在野攻击者已有清理日志、篡改组件和维持持久化的能力，ICT 只能作为证据之一，建议按“设备已失陷”处理。

排查可以分三段做：

先保全，再重置。记录当前版本、设备时间、集群节点状态和 ICT 结果，导出系统日志、审计日志、VPN 登录记录、配置备份及 support bundle。不要一上来就恢复出厂，否则会丢掉时间线。若仍是 22.7R2.5 及更早版本，应先隔离公网管理面，并按 Ivanti 公告升级到 22.7R2.6 或后续修复版本；已发现异常时，更稳妥的做法是完整 factory reset 后从可信配置恢复，而不是仅覆盖升级。
重建设备侧时间线。重点关注首次异常 ICT 结果前后的管理员登录、配置变更、异常重启、日志缺口、计划外证书变化，以及 Web/VPN 请求量突增。不要只匹配公开 IOC，尤其要查“日志突然中断后又恢复”和非维护窗口内的节点切换。
向内网反查。同时检索设备内网接口地址和 VPN 地址池。攻击者获得设备执行能力后，横向流量未必表现为普通 VPN 用户登录，源地址可能直接是网关内网地址。

如果日志已经进 SIEM，可以先做两类聚合。下面以 Splunk 为例，字段名需要按实际设备调整：

index=network earliest=-30d
(src_ip=<Ivanti内网IP> OR src_ip IN (<VPN地址池>))
| stats count min(_time) AS first_seen max(_time) AS last_seen
        values(dest_port) AS ports values(action) AS actions
  by src_ip dest_ip
| convert ctime(first_seen) ctime(last_seen)
| sort - count

index=auth earliest=-30d
(src_ip=<Ivanti内网IP> OR src_ip IN (<VPN地址池>))
| stats count values(user) AS users values(host) AS hosts
        min(_time) AS first_seen max(_time) AS last_seen
  by src_ip, app
| where app IN ("ssh","rdp","smb","winrm","ldap","kerberos")
| convert ctime(first_seen) ctime(last_seen)

内网侧优先核对以下行为：

网关或 VPN 地址池访问域控的 88、389/636、445、135、5985/5986 端口；
同一 VPN 用户短时间访问大量主机，或登录地域、设备指纹与历史不一致；
服务账号从未见过的源地址登录，尤其是备份、虚拟化、运维和目录同步账号；
终端出现远程服务创建、计划任务、WMI/WinRM 执行或异常 SMB 管理共享访问；
DNS、代理和防火墙日志中，以网关地址发起的外联或低频周期连接。

Windows 侧可围绕网关地址和可疑时间窗检查 4624、4648、4672、4688、4698、7045 等事件。例如：

Get-WinEvent -FilterHashtable @{
  LogName='Security'
  Id=4624,4648,4672,4688,4698
  StartTime=(Get-Date).AddDays(-30)
} | Where-Object {
  $_.Message -match '<Ivanti内网IP或VPN网段正则>'
} | Select-Object TimeCreated, Id, MachineName, Message

处置阶段还应轮换所有可能经过设备或可被其访问的凭据：本地管理员、LDAP/AD 绑定账号、RADIUS/TACACS 密钥、API 密钥、服务账号及设备证书私钥。仅强制 VPN 用户改密码通常不够。集群环境要逐节点检查和重建，不能因为主节点 ICT 正常就默认其他节点安全。

最后建议明确调查起点：至少回溯到设备最后一次确认安全的补丁日期，而不是从漏洞公开日开始。在野利用通常早于公告，按公告日期截日志很容易漏掉最初入口。

https://www.hackhat.org/Hacker-topic/26949.html/

粉丝

转到主题列表

没有会员查看此页面。

登录