发布于17小时前17小时 近期边界设备仍是定向入侵的高频入口。Ivanti Connect Secure 的 CVE-2025-0282、CVE-2025-22457 均属于已出现真实利用活动的高风险漏洞，攻击者可能在未认证条件下触发内存破坏，并进一步窃取设备凭据、植入持久化组件或转向内网身份系统。对防守方而言，单纯升级固件并不能证明环境未失陷：VPN 设备通常处在日志链路之外，一旦设备上的记录被清理，后续活动只会在认证、DNS、代理和终端日志中留下碎片。以下内容用于已授权环境中的漏洞验证、事件排查和修复验收，不包含漏洞利用载荷。涉及生产设备时，应先保存配置、日志和取证镜像，再执行升级或恢复出厂操作。一、动态背景与风险边界CVE-2025-0282 影响部分 Ivanti Connect Secure、Policy Secure 与 Neurons for ZTA Gateway 版本；CVE-2025-22457 后续也被确认存在在野利用。两者的共同风险并不只是设备异常重启，而是边界设备掌握了大量高价值信息，包括 LDAP 或 RADIUS 服务账号、VPN 会话、用户身份映射、内部 DNS 信息及可达网段。在实际事件中，常见攻击链可概括为：边界设备漏洞利用、设备侧持久化或凭据访问、使用合法 VPN 身份进入内网、探测 AD 与文件服务、通过远程服务横向移动。由于后半段经常使用有效账号，传统基于恶意文件特征的检测容易漏报。二、问题定位：先确认暴露面，再判断是否失陷第一步不是直接扫描整个互联网，而是从资产台账、DNS、证书平台和防火墙策略中确认本单位实际暴露的设备。重点核对管理面是否对公网开放、设备当前分支版本、最后升级时间，以及是否启用了外部 LDAP、RADIUS、SAML 或 Syslog。确认公网 VIP、管理地址和真实后端地址，避免只检查负载均衡器。导出设备系统日志、管理员审计日志、VPN 登录日志和完整配置备份。记录设备时间、NTP 状态和日志时区，防止跨日志关联时出现偏差。对照厂商公告核验修复版本，不要仅依赖页面显示的主版本号。检查集中日志平台是否存在异常中断；日志突然停止本身就是调查线索。在授权网络中，可以使用低影响方式确认 HTTPS 服务、证书和页面特征。该步骤只用于资产识别，不能替代版本核验，也不应以异常响应作为漏洞存在的结论。target="vpn.example.org" # 保存证书信息，核对证书主体、签发者和有效期 openssl s_client -connect "${target}:443" -servername "${target}" </dev/null 2>/dev/null \ | openssl x509 -noout -subject -issuer -serial -dates -fingerprint -sha256 # 获取响应头并记录重定向、Cookie 和安全头，不发送漏洞载荷 curl -ksS --connect-timeout 5 --max-time 10 -D headers.txt -o /dev/null \ " sed -n '1,30p' headers.txt三、技术分析：漏洞验证不能只看设备是否在线此类内存安全漏洞在验证阶段容易出现两个误区。其一，设备没有崩溃并不代表利用失败；其二，升级后的设备能够正常提供服务，也不能排除升级前已被植入持久化组件。更可靠的判断需要同时覆盖版本、完整性、历史日志和内网行为。检查层面关键证据常见异常设备版本构建号、补丁号、升级记录主版本看似正确，但构建号低于修复版本设备完整性厂商完整性检查结果、文件时间线未知文件、系统文件变化、检查工具告警身份认证VPN、LDAP、RADIUS、SAML 日志非常用地区登录、休眠账号登录、短时多源切换内网行为DNS、NetFlow、EDR、Windows 事件VPN 地址访问域控、管理共享或大量主机日志链路Syslog 接收量和序列连续性设备仍在线但日志突然中断或明显减少若厂商提供外部完整性检查工具，应优先使用官方最新版本，并完整保存原始输出、执行时间和哈希值。完整性检查通过只能降低已知篡改的可能性，不能作为唯一排除依据；发现异常时，应按照厂商事件响应建议执行重建或恢复出厂，而不是只删除可疑文件。四、日志排查：从 VPN 会话还原后续横向链路调查窗口建议至少覆盖漏洞公开或设备暴露之日前 30 天，并根据日志留存情况继续向前扩展。先将 VPN 分配地址、用户、源公网地址、登录时间和会话结束时间整理成会话表，再关联域控、DNS、代理、防火墙与终端日志。Linux Syslog 汇总节点上可先做低成本筛查。实际字段名称应根据设备日志格式调整，不宜只用单一关键词直接定性。# 定位认证、管理员操作、完整性检查和日志服务异常 zgrep -Eai 'login|authentication|admin|integrity|syslog|restart|upgrade' \ /var/log/remote/vpn/*.log* > vpn_review.log # 统计成功登录中的源地址和账号组合，寻找罕见来源 awk 'BEGIN{IGNORECASE=1} /login/ && /success/ {print $0}' vpn_review.log \ | sort | uniq -c | sort -nr | head -100 # 查看日志文件是否存在时间断层 find /var/log/remote/vpn -type f -printf '%TY-%Tm-%Td %TH:%TM:%TS %s %p\n' \ | sort > vpn_log_timeline.txtWindows 域环境中需要重点关注以下事件：4624 成功登录、4625 登录失败、4648 使用显式凭据、4672 特权登录、4768 Kerberos TGT 请求、4769 服务票据请求、4776 NTLM 凭据验证、7045 新服务安装。若日志平台支持查询，应以 VPN 地址池为起点，而不是泛查全部账号。// Microsoft Sentinel / Defender XDR 示例：替换为实际 VPN 地址池 let startTime = ago(30d); let vpnRange = "10.60.0.0/16"; DeviceLogonEvents | where Timestamp > startTime | where ipv4_is_in_range(RemoteIP, vpnRange) | summarize FirstSeen=min(Timestamp), LastSeen=max(Timestamp), Hosts=dcount(DeviceName), HostList=make_set(DeviceName, 20), Actions=make_set(ActionType, 10) by AccountName, RemoteIP | where Hosts > 3 | order by Hosts desc上面的阈值仅用于初筛。运维跳板账号可能正常访问多台设备，而普通用户从 VPN 地址在短时间内访问域控、文件服务器和多台工作站，则更值得调查。建议继续关联 4769 事件中的 ServiceName：短时间请求大量 CIFS、HOST、LDAP 或 MSSQLSvc 服务票据，可能表示服务枚举或横向访问。五、操作步骤：形成可复核的调查闭环冻结变更：记录设备版本、运行时间、NTP、当前会话和管理员登录状态，避免先重启导致易失证据丢失。保存证据：导出配置与日志，对文件计算 SHA-256，并记录采集人、时间和来源设备。核验补丁：根据具体产品分支比对厂商修复版本；无法确认时联系资产负责人，不凭页面特征猜测。执行完整性检查：保留官方工具原始报告。若报告异常，立即限制设备到内网的访问范围，并启动重建流程。梳理身份：列出设备可读取或使用的 LDAP、RADIUS、API、SNMP 和本地管理员凭据，按暴露程度安排轮换。关联内网日志：将 VPN 会话映射到 Windows 登录、Kerberos、DNS、代理、EDR 和 NetFlow，重点检查会话开始后的前 60 分钟。开展受控验证：在维护窗口内确认升级后版本、管理面访问控制、日志外发和告警规则均有效，不进行破坏性利用复现。证据文件可使用以下方式生成校验清单，后续分析始终操作副本：case_dir="IR-2025-VPN-001" mkdir -p "${case_dir}/evidence" "${case_dir}/working" # 将已导出的日志放入 evidence 后生成哈希清单 find "${case_dir}/evidence" -type f -print0 \ | sort -z \ | xargs -0 sha256sum > "${case_dir}/SHA256SUMS.txt" # 验证证据是否发生变化 sha256sum -c "${case_dir}/SHA256SUMS.txt"六、风险控制与修复建议若确认设备处于受影响版本但暂未发现入侵证据，应立即升级到厂商明确标注的修复构建，同时限制管理面来源、关闭不必要接口，并确保日志实时发送到独立平台。不要把临时缓解措施当作永久修复。若完整性检查异常，或发现设备账号被用于内网横向，建议按“边界设备已完全失陷”处理：从可信介质恢复出厂并安装修复版本，不在原系统上做就地清理。轮换设备本地管理员、LDAP 绑定账号、RADIUS 密钥、API Token、SNMP 凭据及可能暴露的证书私钥。撤销现有 VPN 会话、刷新 SAML 签名或加密相关密钥，并检查身份提供商中的异常应用和管理员操作。通过防火墙将 VPN 地址池限制到必要业务端口，禁止直接访问域控管理接口、SMB 管理共享、WinRM 和远程注册表。在 SIEM 中建立基线：同一用户短时跨地区登录、VPN 登录后访问多台主机、非运维账号请求大量服务票据、设备 Syslog 中断。对事件窗口内出现的高权限账号执行专项审计，确认是否新增服务、计划任务、启动项、本地管理员或远程管理配置。权限边界方面，VPN 用户不应因“已经通过 MFA”而获得广泛内网可达性。MFA 可以降低密码泄露风险，但无法消除会话劫持、设备侧凭据读取和已认证会话滥用。更有效的措施是按用户组、设备合规状态和目标业务实施最小访问策略，并对 VPN 到管理网段的流量做显式拒绝。七、总结本轮 Ivanti Connect Secure 漏洞动态再次说明，边界设备修补与事件排查必须同时进行。可靠的处置顺序应是：确认暴露资产、保存设备证据、核验修复构建、执行官方完整性检查、以 VPN 会话为线索关联内网日志、轮换可能暴露的凭据，并通过网络分段和集中日志补齐长期防护。最终验收不能只看漏洞扫描结果，还应确认管理面已收敛、日志持续外发、身份密钥完成轮换，且事件窗口内没有未解释的横向行为。 服务器、云资产与权限边界梳理示意 安全动态、影响面和处置建议示意
15小时前15小时 这类事件不建议只盯着漏洞请求特征。Ivanti Connect Secure 一旦确认被利用，应按“边界设备已失陷、设备日志可能被篡改”处理，重点从设备外部还原内网链路。 第一步先固定 VPN 会话映射。 导出认证、登录/退出、分配虚拟 IP、源公网 IP、用户名和时间戳，统一时区后建立： 公网源 IP → VPN 用户 → 虚拟 IP → 会话起止时间 → 内网目标 随后在防火墙、NetFlow、DNS、代理和 EDR 中，以虚拟 IP 加会话时间窗反查。不要只按用户名搜索，因为攻击者可能复用合法会话或窃取已有凭据。优先关注 VPN 地址池对域控、跳板机、虚拟化管理、备份系统以及 SMB/RDP/WinRM/LDAP/Kerberos 的访问。 Splunk 中可以先做一轮目标端口聚合，字段名按实际日志调整： index=firewall src_ip IN ("VPN地址池CIDR") (dest_port IN (53,88,135,139,389,445,464,636,3389,5985,5986,8006,8443)) | bin _time span=5m | stats count dc(dest_ip) AS target_count values(dest_port) AS ports values(dest_ip) AS targets BY _time,src_ip | where target_count > 10 OR mvcount(ports) > 4 | sort 0 _time 第二步在 Windows 侧验证横向活动。 建议关联 4624、4625、4648、4672、4688、4768、4769、4776 和 5140/5145。重点看 LogonType 3/10、显式凭据使用、异常服务创建，以及短时间访问多台主机。若已部署 Sysmon，再补查事件 1、3、10、11、13、22。PowerShell 可快速筛选 VPN 地址段来源的登录： $start = (Get-Date).AddDays(-7) Get-WinEvent -FilterHashtable @{ LogName = 'Security' Id = 4624,4625,4648,4672,4768,4769,4776 StartTime = $start } | Where-Object { $_.Message -match '10\.20\.(4[0-9]|5[0-9])\.' } | Select-Object TimeCreated, Id, MachineName, Message | Export-Csv .\ivanti-vpn-auth-review.csv -NoTypeInformation -Encoding UTF8 设备本身的日志只能作为辅证。 应先保存系统快照、配置、审计日志和厂商 Integrity Checker 结果，再做处置。内部完整性检查若依赖设备自身组件，不能单独作为“未失陷”结论；应结合厂商提供的外部检查方式、上游网络日志和终端遥测。发现完整性异常、未知 Web 组件、计划任务或配置被改动时，不建议仅删除文件后继续上线，应按厂商流程重置或重建，并升级到已修复版本。 凭据处置要覆盖设备可接触的信任关系。 至少轮换本地管理员、LDAP/AD 绑定账号、RADIUS/TACACS 密钥、API 密钥、证书私钥及可能经过该设备的高权限账号；同时撤销现有 VPN 会话和令牌。轮换顺序应先隔离或重建设备，再更换凭据，否则新凭据仍可能被再次获取。 最后建议把排查窗口向首次可疑请求之前扩展至少数天。此类设备常见情况是漏洞触发时间不等于首次驻留时间，单纯从告警当天开始查，容易漏掉前期凭据窃取和低频横向。
