近期内网入口被利用的真实趋势——从边界 VPN 日志看授权渗透中的权限扩展链路

发布于10月10日10月10日

背景

最近几周在多个授权评估项目和蓝队复盘里，边界 VPN、统一身份认证、堡垒机成为最常见的初始入口。这里不讨论具体厂商 0day 细节，也不做泛泛新闻汇总，重点说一个更值得关注的趋势：攻击者拿到边界账号后，并不一定立刻打漏洞，而是先利用正常登录、弱权限配置和日志盲区，完成内网侦察、横向访问和权限扩展。

这类事件在威胁情报里通常被归为“合法凭据滥用”或“Living off the Land”，但在授权渗透测试中，它对应的是一条很实际的链路：VPN 登录成功 → 内网网段探测 → 域内服务枚举 → 凭据复用 → 文件共享或远程管理协议横向 → 提权或数据访问。

本文只讨论授权环境下的验证和排查方法，重点放在日志留痕、权限边界和修复建议。

典型场景

某企业开启 SSL VPN，账号接入后默认可以访问多个办公网段。测试中使用一个低权限账号登录 VPN，发现分配地址为 10.20.8.0/24，访问策略允许到 10.10.0.0/16 的大部分端口。账号本身没有管理员权限，但由于内网主机开放 SMB、WinRM、RDP，且存在本地管理员密码复用，最终可以从普通办公终端横向到运维跳板机。

这类问题不是单点漏洞，而是几个配置叠加：

VPN 账号缺少最小权限访问控制，登录后默认放通大网段。
内网资产缺少分区隔离，办公区可访问服务器管理端口。
Windows 本地管理员密码复用，导致一次凭据命中后横向扩大。
认证日志、VPN 日志、Windows 安全日志没有统一关联，事件发现滞后。

问题定位

排查时不要只看“有没有漏洞利用痕迹”，合法凭据登录往往没有 WebShell、没有明显木马。建议先按时间线关联三类日志：

VPN 网关日志：登录账号、源 IP、分配内网地址、登录时间、断开时间、访问目的地址。
域控日志：Kerberos、NTLM 认证、异常失败、服务票据请求。
终端日志：Windows 4624、4625、4672、4688、5140、7045、PowerShell 4104。

重点看几个异常点：

同一账号短时间从陌生公网 IP 登录 VPN。
VPN 地址访问大量 445、3389、5985、135、139 端口。
普通用户在多台主机上出现 4624 Type 3 或 Type 10 登录。
登录后紧接着出现 4672 特权分配事件，说明该账号在目标机上具备管理员权限。
出现远程服务创建 7045，或命令行里包含 net、wmic、powershell、winrm 等远程管理行为。

技术分析

以 Windows 域环境为例，攻击链路并不复杂，但日志特征比较清晰。VPN 分配地址访问内网主机后，如果使用 SMB 认证，目标主机会记录 4624 登录事件，LogonType 通常是 3；如果通过 RDP 登录，则通常是 Type 10；如果账号在目标机属于本地 Administrators 组，还会看到 4672。

在域控侧，如果存在大量 4769 服务票据请求，且服务名集中在 cifs、host、termsrv，通常说明账号正在访问文件共享、远程管理或远程桌面服务。若失败日志 4771、4776 明显增加，要考虑爆破或密码喷洒。

授权渗透中验证权限边界时，可以先不进行漏洞利用，只确认网络访问面和认证路径。例如从 VPN 地址段测试哪些网段可达、哪些管理端口开放，再结合域账号权限确认是否存在横向条件。

操作步骤

下面是一套偏蓝队复盘和授权验证的流程，适用于近期这类“边界账号进入内网后横向”的事件排查。

第一步：导出 VPN 最近 7 到 30 天登录日志，筛选异地登录、非工作时间登录、失败后成功登录。
第二步：提取 VPN 分配的内网地址，与防火墙会话日志关联，统计访问最多的目标 IP 和端口。
第三步：在域控检索相关账号的 4768、4769、4771、4776 事件，判断认证范围是否异常。
第四步：在被访问主机检索 4624、4672、4688、5140、7045、4104 事件，确认是否存在远程登录、共享访问、命令执行和服务创建。
第五步：验证 VPN 访问策略，确认普通账号是否可以访问服务器区、运维区、域控、数据库等敏感网段。

命令示例

以下命令用于授权环境中的日志排查。示例重点是从 Windows 安全日志中筛选某个 VPN 分配地址或账号的登录痕迹。

# 在目标主机上查询来自 VPN 地址段的成功登录事件，关注 LogonType 3/10
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624; StartTime=(Get-Date).AddDays(-7)} |
Where-Object {
    $_.Properties[18].Value -like '10.20.8.*' -or
    $_.Properties[5].Value -match 'test.user'
} |
Select-Object TimeCreated,
@{n='Account';e={$_.Properties[5].Value}},
@{n='LogonType';e={$_.Properties[8].Value}},
@{n='SourceIP';e={$_.Properties[18].Value}} |
Format-Table -AutoSize

# 查询特权登录事件，确认是否在目标机获得管理员级别权限
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4672; StartTime=(Get-Date).AddDays(-7)} |
Select-Object TimeCreated,
@{n='Account';e={$_.Properties[1].Value}} |
Format-Table -AutoSize

# 在域控查询某账号的 Kerberos 服务票据请求，观察是否集中访问 cifs/host/termsrv
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4769; StartTime=(Get-Date).AddDays(-7)} |
Where-Object { $_.Properties[0].Value -match 'test.user' } |
Select-Object TimeCreated,
@{n='Account';e={$_.Properties[0].Value}},
@{n='ServiceName';e={$_.Properties[2].Value}},
@{n='ClientIP';e={$_.Properties[6].Value}} |
Format-Table -AutoSize

如果环境中有集中日志平台，可以按类似条件建立查询。比如关注 VPN 地址段访问管理端口：

src_ip in 10.20.8.0/24 AND dst_port in (445,3389,5985,5986,135,139,22)
| stats count by src_ip,dst_ip,dst_port,user
| sort count desc

关键配置核查

这类事件的核心不只是账号泄露，而是访问边界过宽。建议重点核查以下配置：

VPN 访问控制是否按用户组绑定最小可访问网段，而不是全网段放通。
普通办公账号是否能访问域控、服务器区、数据库区、备份区。
是否对 VPN 登录强制 MFA，是否限制高风险国家或异常 ASN。
堡垒机是否覆盖所有 SSH、RDP、数据库管理入口。
Windows 本地管理员密码是否使用 LAPS 或 Windows LAPS 管理，避免复用。
WinRM、SMB、RDP 是否只允许管理网段访问。

一个比较有效的防火墙策略思路是：VPN 用户默认只允许访问业务系统端口，不允许访问主机管理端口；确需管理的用户必须进入独立运维 VPN 组，并通过堡垒机或 PAM 系统二次认证。

风险与修复建议

风险点	影响	修复建议
VPN 普通账号可访问大网段	账号泄露后可直接进行内网探测	按用户组拆分 ACL，仅开放必要业务端口
办公区可访问服务器管理端口	增加横向移动机会	限制 445、3389、5985、22 等端口到管理网段
本地管理员密码复用	单台主机失陷后批量扩散	部署 LAPS/Windows LAPS，定期轮换本地管理员密码
缺少 MFA	撞库、钓鱼后可直接登录	VPN、邮箱、堡垒机、云控制台强制 MFA
日志未关联	无法还原登录到横向的时间线	统一接入 VPN、防火墙、域控、终端日志

另外，建议给以下行为设置告警：

VPN 登录后 5 分钟内访问超过 20 个内网 IP。
VPN 地址访问域控 445、135、389、636、88、3389 等敏感端口。
普通用户在多台主机出现 4624 Type 3 且伴随 4672。
非运维账号触发 WinRM、远程服务创建或计划任务创建。
同一账号出现多个地理位置不合理的 VPN 登录。

总结

近期这类事件的共同点是：入口看起来很普通，往往只是一个 VPN 账号；真正的问题出在登录后的权限边界过宽、内网管理端口暴露、本地管理员密码复用和日志割裂。对新闻动态板块来说，值得关注的不只是“某漏洞被利用”，更是攻击者正在减少高噪声漏洞利用，转向低噪声的合法凭据和内网权限链路。

授权渗透测试和蓝队复盘时，可以把验证重点放在三件事上：账号进来后能到哪里、能用什么协议、日志能否还原完整路径。只要这三点收紧，很多看似复杂的内网横向链路都会被提前截断。

10月10日10月10日

从 VPN 日志往内网权限扩展链路看，建议重点别只看“谁登录成功”，而是把登录后的第一跳行为串起来。授权测试里我见到比较多的是：合法 VPN 账号进入后，先打堡垒机/跳板机，再横向到文件服务器、域控周边管理机，最后靠弱口令、缓存凭据或过宽的组策略权限扩展。可以按下面几个点排查，比较贴近真实链路： 1. **VPN 成功登录后的异常源/目的关系** 关注同一账号短时间内： - 登录 IP 地理位置或 ASN 突变； - 非工作时间登录； - 登录后访问了平时不访问的网段； - 从 VPN 地址池直接扫 445/3389/5985/22。如果 VPN 地址池是固定段，可以先在防火墙或流量日志里查：

src_ip in (VPN_POOL)
and dst_port in (445,3389,5985,22,135,139,389,636)
| stats count, dc(dst_ip) as dst_count by user, src_ip, dst_port
| where dst_count > 20

这个比单纯看 VPN 登录失败更有价值，很多利用入口都是一次成功登录后才开始。 2. **把 VPN 账号映射到 AD 行为** 如果 VPN 走 RADIUS/LDAP，建议把 VPN 登录账号和域控事件关联。重点看： - 4624：登录成功，尤其 LogonType 3、10； - 4648：使用显式凭据； - 4672：分配特殊权限； - 4768/4769/4771：Kerberos 认证异常； - 4776：NTLM 认证； - 4728/4732：加入高权限组； - 5136：目录对象变更。 PowerShell 简单筛一下高风险登录：

Get-WinEvent -FilterHashtable @{
  LogName='Security'
  Id=4624
  StartTime=(Get-Date).AddDays(-7)
} | Where-Object {
  $_.Properties[8].Value -in 3,10
} | Select-Object TimeCreated,
  @{n='User';e={$_.Properties[5].Value}},
  @{n='SourceIP';e={$_.Properties[18].Value}},
  @{n='LogonType';e={$_.Properties[8].Value}}

如果看到 VPN 地址池来源直接登录服务器，尤其是非运维账号，基本就要继续追。 3. **第一跳机器上的凭据暴露** 很多权限扩展不是靠漏洞，而是靠第一跳机器上有： - 浏览器保存密码； - 远程桌面历史； - `cmdkey` 保存凭据； - 运维脚本里写死账号密码； - 共享目录里的配置文件。可以在授权范围内快速查：

cmdkey /list

dir /s /b C:\Users\*\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt

findstr /si /m "password passwd pwd secret token jdbc ldap" C:\*.txt C:\*.config C:\*.ini C:\*.ps1

这类东西经常是 VPN 入口到域权限扩大的关键节点。 4. **关注从 VPN 地址池发起的管理协议** 正常情况下，VPN 用户不应该直接管理服务器。建议对以下行为做告警或至少留痕： - VPN 段访问 DC 的 445/135/389/636/88； - VPN 段访问服务器的 5985/5986； - VPN 段大量访问 445； - VPN 段对内网资产做 DNS 枚举。防火墙策略上可以收敛成“VPN 用户只允许访问业务入口和堡垒机”，不要让 VPN 池和服务器网段全通。示例思路：

# 允许 VPN 到堡垒机
allow src VPN_POOL dst BASTION port 22,3389,443

# 允许 VPN 到指定业务系统
allow src VPN_POOL dst APP_SEGMENT port 443

# 拒绝 VPN 直连管理端口
deny src VPN_POOL dst SERVER_SEGMENT port 22,135,139,445,3389,5985,5986

# 拒绝 VPN 访问域控敏感端口，除非确有认证代理需求
deny src VPN_POOL dst DC_SEGMENT port 88,135,139,389,445,464,593,636,3268,3269

5. **入口账号本身要看权限边界** 有些 VPN 账号虽然只是普通用户，但被加入了不该有的组，例如： - 本地管理员组； - 远程桌面用户组； - 运维共享目录读权限； - 某些业务系统后台管理员。可以用 AD 查询近期变更和高权限组成员：

Get-ADGroupMember "Domain Admins" -Recursive
Get-ADGroupMember "Administrators" -Recursive
Get-ADGroupMember "Remote Desktop Users" -Recursive

Get-ADUser -Filter * -Properties MemberOf,LastLogonDate |
Select SamAccountName,LastLogonDate,MemberOf

重点不是只查 DA，而是查“能登录服务器的普通账号”。 6. **日志链路建议按时间线还原** 我通常会按这个顺序拼： - VPN 登录成功时间、源 IP、账号； - 同账号在 AD 上的认证事件； - VPN 地址池到内网资产连接记录； - 第一台被登录主机的 4624/4688； - 是否执行了 `net user`、`whoami`、`nltest`、`ipconfig`、`net view`、`quser` 等枚举命令； - 后续是否出现 SMB、WinRM、RDP 横向。 Windows 进程创建如果开了 4688，可以查这些命令：

Get-WinEvent -FilterHashtable @{
  LogName='Security'
  Id=4688
  StartTime=(Get-Date).AddDays(-7)
} | Where-Object {
  $_.Properties[8].Value -match 'whoami|net\s+user|net\s+group|nltest|ipconfig|quser|qwinsta|wmic|powershell|cmd.exe'
} | Select TimeCreated,@{n='CommandLine';e={$_.Properties[8].Value}}

总结一下，边界 VPN 被利用后，真正危险的不是 VPN 本身，而是 VPN 后面是否默认信任了用户。排查时建议从“VPN 成功登录 + 内网管理协议访问 + AD 认证事件 + 第一跳主机凭据痕迹”这条线串起来，基本能还原大部分权限扩展路径。

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

粉丝

转到主题列表

没有会员查看此页面。

登录