授权内网测试后如何排查权限边界、登录留痕与修复项

发布于昨天 23:271天前

背景

在问答中心里经常有人问：做完一次授权内网渗透测试后，如何确认测试行为没有越过授权边界？哪些日志能证明测试路径？发现了域账号弱口令、共享目录权限过宽、远程登录暴露后，应该怎么给出可落地的修复建议？

这类问题不适合只写“加强安全意识”。下面按一个常见场景拆开：测试方在授权范围内对办公网段进行漏洞验证，涉及 Windows 域环境、文件共享、RDP/WinRM 登录验证、Web 入口弱口令验证。目标是回答三个问题：

哪些行为发生过，是否在授权范围内；
哪些账号、主机、服务留下了关键日志；
如何把发现项转成可执行的加固清单。

问题定位

假设授权范围如下：

网段：10.20.30.0/24、10.20.40.0/24；
域：corp.example.local；
允许验证：端口探测、弱口令验证、已知漏洞验证、最小化命令执行验证；
禁止行为：批量数据下载、持久化、破坏性利用、越权访问非授权网段。

测试结束后，蓝队或管理员需要核对的重点不是“有没有扫描”，而是：

是否出现非授权网段连接，例如 10.30.0.0/16；
是否使用了非授权账号或高权限域账号；
是否有异常登录类型，例如 4624 LogonType 3、10、9；
是否触发了远程服务创建、计划任务、PowerShell 远程执行；
是否有文件共享的大量读取、复制、压缩行为。

技术分析

Windows 域内排查通常从三类日志入手：域控安全日志、目标主机安全日志、终端 PowerShell/系统日志。

日志位置	重点事件	用途
域控 Security	4624、4625、4768、4769、4771、4776	确认账号认证、失败登录、Kerberos 票据申请
目标主机 Security	4624、4627、4672、4688、5140、5145	确认登录类型、管理员权限、进程创建、共享访问
System	7045	确认是否创建新服务
PowerShell	4103、4104	确认脚本块、模块调用、远程执行痕迹
TaskScheduler	106、140、141、200、201	确认计划任务创建与执行

几个事件的判断经验：

4624 LogonType=3：网络登录，常见于 SMB、远程服务、WinRM 等；
4624 LogonType=10：RDP 交互式远程登录，需要重点关注来源 IP；
4624 LogonType=9：使用显式凭据，例如 runas /netonly 类行为；
4672：账号被授予特殊权限，若普通业务账号频繁出现，需要复核权限；
7045：新服务安装，渗透测试中如果使用远程服务验证命令执行，会留下该事件；
5140/5145：共享访问，适合确认是否访问了敏感共享目录。

操作步骤

建议按时间线排查。先让测试方提供测试窗口，例如 2025-01-10 10:00 至 18:00、测试出口 IP、使用的测试账号。没有这些信息，日志排查会非常低效。

第一步：确认测试源 IP 与授权网段；
第二步：在域控检索认证事件，定位账号与目标主机；
第三步：在目标主机检索登录、进程、服务、计划任务日志；
第四步：检查共享访问和敏感文件读取；
第五步：整理出越界行为、弱配置、修复建议。

代码/命令示例

下面是一个比较实用的 PowerShell 检索示例，用于在单台 Windows 主机上筛选指定时间段内来自测试源 IP 的登录事件、服务创建事件和 PowerShell 脚本块日志。实际环境建议通过 SIEM、WEC 或 EDR 批量查询。

$Start = Get-Date "2025-01-10 10:00:00"
$End   = Get-Date "2025-01-10 18:00:00"
$TesterIPs = @("10.20.30.55", "10.20.30.56")

Write-Host "[+] Security 4624/4625 login events"
Get-WinEvent -FilterHashtable @{
    LogName='Security'
    Id=4624,4625
    StartTime=$Start
    EndTime=$End
} | ForEach-Object {
    $xml = [xml]$_.ToXml()
    $data = @{}
    foreach ($d in $xml.Event.EventData.Data) { $data[$d.Name] = $d.'#text' }

    if ($TesterIPs -contains $data['IpAddress']) {
        [PSCustomObject]@{
            TimeCreated = $_.TimeCreated
            EventId     = $_.Id
            Account     = "$($data['TargetDomainName'])\$($data['TargetUserName'])"
            LogonType   = $data['LogonType']
            SourceIP    = $data['IpAddress']
            Workstation = $data['WorkstationName']
            Process     = $data['ProcessName']
        }
    }
} | Format-Table -AutoSize

Write-Host "[+] System 7045 service creation events"
Get-WinEvent -FilterHashtable @{
    LogName='System'
    Id=7045
    StartTime=$Start
    EndTime=$End
} | Select-Object TimeCreated, Id, ProviderName, Message | Format-List

Write-Host "[+] PowerShell 4104 script block events"
Get-WinEvent -FilterHashtable @{
    LogName='Microsoft-Windows-PowerShell/Operational'
    Id=4104
    StartTime=$Start
    EndTime=$End
} -ErrorAction SilentlyContinue | Select-Object TimeCreated, Id, Message | Format-List

如果在域控上排查 Kerberos 认证，可以重点看 4768 和 4769。下面这个命令用于快速筛选某个账号在测试窗口内的票据申请行为：

$User = "test.audit"
Get-WinEvent -FilterHashtable @{
    LogName='Security'
    Id=4768,4769,4771
    StartTime=(Get-Date "2025-01-10 10:00:00")
    EndTime=(Get-Date "2025-01-10 18:00:00")
} | Where-Object { $_.Message -match $User } |
Select-Object TimeCreated, Id, Message |
Format-List

Linux 侧如果有 SSH 登录验证，可以从 auth 日志里按源 IP 和时间过滤：

# Debian/Ubuntu
zgrep -hE "Accepted|Failed|Invalid user|session opened" /var/log/auth.log* \
  | grep "10.20.30.55"

# RHEL/CentOS
zgrep -hE "Accepted|Failed|Invalid user|session opened" /var/log/secure* \
  | grep "10.20.30.55"

排查结果如何判断

建议把结果分成三类，方便在问答或复盘里说清楚。

类型	判断标准	处理方式
授权内行为	时间、账号、源 IP、目标均在授权范围	记录证据，归档测试路径
疑似越界行为	目标 IP 或账号不在授权清单，但可能是跳转、解析或资产登记错误	暂停相关验证，补充确认资产归属
明确越界行为	访问非授权网段、使用非授权账号、读取非测试数据	立即上报，保留日志，做影响评估

一个常见误区是只看扫描器报告，不看认证日志。比如报告里只有“SMB 弱口令验证成功”，但日志里可能显示该账号随后访问了多个共享路径。此时应该结合 4624、4672、5140、5145 判断实际访问范围，而不是只看漏洞标题。

风险与修复建议

针对这类授权测试中经常暴露的问题，修复建议要尽量具体。

弱口令或复用密码：启用域密码策略，最小长度不少于 12 位；对管理员组账号单独启用更高复杂度；排查同口令本地管理员账号。
共享目录权限过宽：检查 Everyone、Authenticated Users、Domain Users 是否拥有写入或读取敏感目录权限；对财务、人事、研发目录做最小权限拆分。
RDP 暴露过多：限制来源 IP；开启 NLA；普通办公账号禁止直接 RDP 到服务器；关键服务器通过堡垒机审计。
WinRM/远程服务缺少审计：开启 PowerShell Script Block Logging、Module Logging；将 4103、4104、4688、7045 接入集中日志平台。
域管理员使用不规范：域管账号只允许登录域控和管理跳板机；禁止在普通终端、业务服务器上交互式登录。
日志保留不足：域控 Security 日志建议根据登录量调整到足够容量，至少覆盖 30 天；关键服务器日志集中转发，避免本地覆盖。

可参考的审计策略配置方向：

# 查看当前审计策略
auditpol /get /category:*

# 开启进程创建审计
auditpol /set /subcategory:"Process Creation" /success:enable /failure:enable

# 开启登录事件审计
auditpol /set /subcategory:"Logon" /success:enable /failure:enable

# 开启文件共享审计
auditpol /set /subcategory:"File Share" /success:enable /failure:enable
auditpol /set /subcategory:"Detailed File Share" /success:enable /failure:enable

总结

授权内网测试后的复盘，不是简单确认“漏洞有没有修”，而是要把测试行为、权限边界和日志证据串起来。比较稳妥的做法是：先限定时间、源 IP、账号和范围，再围绕域控认证日志、目标主机登录日志、服务/计划任务/PowerShell 日志逐项核对。

在问答中心提问时，建议至少提供：授权范围、测试时间、涉及账号、目标系统类型、已发现的事件 ID 或日志片段。这样别人才能基于具体证据帮你判断是正常验证、配置风险，还是已经出现越界访问。

23小时前23小时

这个场景建议先把“测试动作”和“业务权限边界”拆开看，不然最后很容易只得到一堆漏洞点，修复时不好落地。可以按下面几块排查。

1. 权限边界：先确认账号、系统、网络三层边界

账号层面重点看测试账号是否拿到了不该有的角色、组、菜单、数据范围：

普通用户能否访问管理员接口，例如 /admin、/api/user/list、/api/role/update。
同角色不同部门/租户之间是否能越权访问数据。
修改请求中的 userId、deptId、tenantId、roleId 是否能越权。
接口是否只在前端隐藏按钮，后端没有做鉴权。

如果是 Web 系统，建议直接抓包做一轮横向/纵向越权验证，例如：

GET /api/order/detail?id=10001
Cookie: 普通用户A

GET /api/order/detail?id=10002
Cookie: 普通用户A
# 10002 属于用户B，看是否返回

后端修复上不要只依赖前端菜单，接口层要做强制校验，例如伪代码逻辑应该是：

// 不要只判断是否登录
if (!currentUser.hasPermission("order:read")) {
    return 403;
}

// 数据范围也要校验
Order order = orderService.getById(orderId);
if (!order.getOwnerId().equals(currentUser.getId())
    && !currentUser.hasDataScope(order.getDeptId())) {
    return 403;
}

主机层面建议检查测试账号是否被加进了高权限组：

# Linux
id testuser
groups testuser
sudo -l -U testuser
getent group sudo
getent group wheel

# 查最近新增用户和 sudo 变更
grep -E "useradd|adduser|usermod|sudo" /var/log/auth.log /var/log/secure 2>/dev/null

Windows 域环境可以看本地管理员组和域组成员关系：

net localgroup administrators
net user testuser /domain
net group "Domain Admins" /domain
net group "Remote Desktop Users" /domain

网络层面确认测试来源 IP 是否只能访问授权范围，不要因为临时放通导致全网可达：

# 从测试机确认可达范围
nmap -sT -Pn -p 22,80,443,3389,3306,5432,6379,9200 10.0.0.0/24

# Linux 主机查看监听服务
ss -lntup

# 防火墙规则
iptables -S
firewall-cmd --list-all

这里重点不是扫得多全，而是确认是否存在“测试网段能访问生产核心库、Redis、ES、运维面板”这类边界失控。

2. 登录留痕：确认能追溯到人、时间、来源、操作

登录留痕建议至少覆盖：

登录成功/失败时间。
账号、来源 IP、User-Agent。
MFA 是否通过。
Token/Session 创建与失效。
关键操作：改密码、改角色、导出数据、删除数据、配置变更。

Linux 上可以先查这些位置：

# Debian/Ubuntu
grep "Accepted\|Failed\|session opened\|sudo" /var/log/auth.log

# RHEL/CentOS
grep "Accepted\|Failed\|session opened\|sudo" /var/log/secure

# 最近登录
last -a
lastb -a
lastlog

Windows 建议重点看安全日志：

# 登录成功 4624，失败 4625，注销 4634，远程登录类型通常关注 LogonType 10/3
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624,4625,4634} |
Select-Object TimeCreated, Id, ProviderName, Message -First 20

Web 应用如果日志里只有“登录成功”但没有来源 IP 和用户标识，后续基本没法溯源。可以统一成结构化日志，例如：

{
  "event": "login_success",
  "user_id": "12345",
  "username": "zhangsan",
  "src_ip": "10.1.2.3",
  "user_agent": "Mozilla/5.0 ...",
  "session_id_hash": "sha256_xxx",
  "mfa": true,
  "time": "2026-10-11T10:22:31+08:00"
}

注意不要把明文密码、完整 Token、Cookie 写进日志。Session ID 可以做 hash 后记录，用于关联即可。

3. 测试后清理项：不要只清账号，也要清临时策略

授权测试结束后，建议形成一张“临时变更清单”，逐项回滚：

临时测试账号是否禁用或删除。
临时加入的管理员组、sudo 权限是否移除。
临时防火墙白名单、VPN 权限是否撤销。
临时上传的 WebShell、脚本、探测工具、压缩包是否删除。
临时数据库账号、API Key、AccessKey 是否吊销。
测试期间生成的报告、数据导出文件是否按要求留存或销毁。

可以用一些简单命令辅助确认：

# 查最近 7 天修改的可疑文件
find /var/www /opt -type f -mtime -7 -ls 2>/dev/null

# 查临时目录可执行文件
find /tmp /var/tmp -type f -perm /111 -ls 2>/dev/null

# 查 crontab
crontab -l
ls -la /etc/cron* /var/spool/cron 2>/dev/null

# 查 SSH key
find /home /root -name authorized_keys -type f -exec ls -l {} \; -exec cat {} \;

4. 修复项优先级建议

如果时间有限，建议按风险排序处理：

越权访问：尤其是跨用户、跨部门、跨租户数据读取/修改。
弱口令和默认口令：内网里很常见，影响面通常比单点漏洞大。
管理面暴露：如 Jenkins、Nacos、Grafana、数据库、Redis、ES、RDP、SSH。
日志缺失：没日志会导致事件发生后无法定责和复盘。
临时授权未回收：测试结束后最容易遗留。

最后建议把结果按“问题现象、影响范围、复现条件、证据、修复建议、验证方式”来写。尤其是权限边界类问题，最好附上两个不同权限账号的请求和响应对比，这样研发修起来会明确很多。

创建帐户或登录后发表意见

注册帐户

立刻登录

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

粉丝

转到主题列表

没有会员查看此页面。

登录