授权内网渗透中如何确认 SMB 横向访问是否越权并留痕排查

发布于5小时前5小时

背景

最近在问答区看到类似问题：客户授权的内网渗透中，拿到一组域账号后，发现可以访问多台 Windows 服务器的 ADMIN$、C$ 或业务共享目录。问题是：如何判断这是正常权限、配置过宽，还是已经构成横向越权风险？同时测试动作如何留痕、如何给出可修复的结论。

这个问题不适合只回答“看权限”三个字。实际项目里需要同时确认账号身份、组关系、共享权限、NTFS 权限、登录事件、访问事件和域策略，否则报告很容易写成泛泛描述，客户也不好整改。

具体场景

假设测试范围内有一个域：corp.local，测试账号为 CORP\audit.test。授权目标包括：

10.10.20.11：文件服务器
10.10.20.21：应用服务器
10.10.20.31：普通办公终端

在测试过程中发现 audit.test 能访问 \\10.10.20.21\C$ 或 \\10.10.20.11\Finance，需要判断是否越权。

问题定位思路

建议按下面顺序排查，不要一上来就扫全网共享或批量尝试管理员共享，容易扩大影响，也会给日志带来噪音。

确认账号是否属于本地 Administrators、Domain Admins、Server Operators 等高权限组。
确认共享权限和 NTFS 权限是否同时放行。Windows 访问共享时取两者交集。
确认是否存在“域用户默认可读”“Everyone 可写”“Authenticated Users 修改”等配置。
确认访问是否触发交互登录、网络登录或特殊权限登录事件。
确认测试行为是否在授权窗口内，并记录来源 IP、账号、目标和时间点。

技术分析

Windows 共享访问涉及两个层面的权限：

共享权限：在共享层控制，例如 Read、Change、Full。
NTFS 权限：文件系统 ACL，例如 Read、Modify、FullControl。

实际访问权限通常是两者中更严格的结果。比如共享权限给了 Everyone Full，但 NTFS 只给 Domain Users Read，那普通域用户最终只能读。反过来，如果 NTFS 给了 Authenticated Users Modify，即便共享层只给 Change，也可能形成业务目录被篡改的风险。

对于 C$、ADMIN$ 这类管理共享，普通域用户不应访问成功。如果普通账号能访问，常见原因包括：

该账号被加入目标主机本地 Administrators。
域组被通过 GPO 加入了本地 Administrators。
历史运维脚本错误配置了本地管理员组。
使用的是具备本地管理员权限的服务账号。

操作步骤

以下步骤建议在已授权、最小化影响的前提下执行。不要对非授权网段做枚举。

1. 确认当前账号身份与组关系

whoami /user
whoami /groups
net user audit.test /domain

重点看是否存在以下组：

Domain Admins
Enterprise Admins
Administrators
Account Operators
Server Operators
客户自定义的运维组，例如 IT-Admin、Server-Maintainers

如果账号属于某个业务组，不要直接判断为安全，需要继续看该组是否通过 GPO 下发到本地管理员组。

2. 对单台目标验证管理共享访问

net use \\10.10.20.21\C$ /user:CORP\audit.test *
dir \\10.10.20.21\C$\
net use \\10.10.20.21\C$ /delete

这里建议只做目录枚举，不要写入文件，除非授权明确要求进行写入验证。若必须验证写权限，建议使用固定测试文件名，并测试后立即删除，例如 pt_authorized_test.txt。

3. 检查目标主机本地管理员组

如果有目标主机本地管理权限，可以在目标上执行：

net localgroup administrators

也可以使用 PowerShell 查询远程本地组成员，前提是当前权限和防火墙策略允许：

Get-LocalGroupMember -Group "Administrators"

若看到类似：

CORP\Domain Users
CORP\IT-Helpdesk
CORP\audit.test

则需要重点确认是否为误配置。尤其是 Domain Users 被加入本地管理员，属于严重权限边界失效。

4. 检查共享权限和 NTFS 权限

在文件服务器上可以执行：

Get-SmbShare
Get-SmbShareAccess -Name Finance
icacls D:\Shares\Finance

一个高风险示例：

Get-SmbShareAccess -Name Finance

Name    ScopeName AccountName            AccessControlType AccessRight
----    --------- -----------            ----------------- -----------
Finance *         Everyone               Allow             Full
Finance *         CORP\Domain Users      Allow             Change

icacls D:\Shares\Finance
D:\Shares\Finance BUILTIN\Administrators:(OI)(CI)(F)
                  CORP\Domain Users:(OI)(CI)(M)
                  NT AUTHORITY\SYSTEM:(OI)(CI)(F)

这里 Domain Users 对财务目录拥有 Modify 权限，普通域用户可修改文件，通常可以判定为越权配置。

5. 查看关键日志留痕

测试完成后应把验证时间、源 IP、目标 IP、账号和动作写进工作记录，并建议客户核对日志。Windows 上重点关注这些事件：

4624：登录成功，网络登录通常是 Logon Type 3。
4625：登录失败。
4672：分配了特殊权限，常见于管理员登录。
5140：访问了网络共享对象。
5145：检查了共享对象访问权限，需开启详细文件共享审计。

可以用 PowerShell 在目标主机上按时间窗口过滤：

$start = Get-Date "2026-01-10 10:00:00"
$end   = Get-Date "2026-01-10 10:30:00"

Get-WinEvent -FilterHashtable @{
    LogName='Security'
    Id=4624,4672,5140,5145
    StartTime=$start
    EndTime=$end
} | Select-Object TimeCreated, Id, ProviderName, Message

如果没有 5140 或 5145，不代表没有访问过，可能是对象访问审计没有开启。可检查本地安全策略或域策略：

auditpol /get /subcategory:"File Share"
auditpol /get /subcategory:"Detailed File Share"

6. 判断是否越权的标准

建议用可验证标准来写结论，而不是写“疑似存在风险”。

现象	判断	证据
普通域账号可访问 C$	高风险，权限边界失效	账号组关系、本地 Administrators 成员、4624/4672 日志
Domain Users 可修改业务共享	高风险，业务数据可被篡改	Get-SmbShareAccess、icacls 输出、写入验证记录
Everyone 对共享 Full，但 NTFS 限制为只读	中低风险，配置不规范	共享权限与 NTFS 权限对比
服务账号可登录多台服务器并访问管理共享	高风险，横向移动面扩大	服务账号用途说明、本地管理员组、登录日志

风险与修复建议

清理本地管理员组：不要将 Domain Users、普通业务组、共享服务账号加入本地 Administrators。
按角色拆分权限：文件共享建议按部门、岗位、读写需求拆分 AD 组，例如 FS-Finance-Read、FS-Finance-Modify。
共享权限保持收敛：共享层不要长期使用 Everyone Full，建议只授权明确的域组。
NTFS 权限避免继承污染：业务目录单独设置 ACL，定期检查是否继承了上级目录的宽权限。
限制服务账号交互和网络登录：通过 GPO 配置 Deny log on locally、Deny log on through Remote Desktop Services，并限制可登录主机。
开启审计：至少开启 Logon、Account Logon、File Share、Detailed File Share 审计，并将日志接入集中平台。
最小化验证动作：授权测试中尽量使用只读验证；如需写入，使用固定测试文件，记录哈希和删除时间。

报告中建议保留的证据

测试账号：例如 CORP\audit.test。
测试来源 IP 与目标 IP。
验证时间窗口。
whoami /groups 输出。
Get-SmbShareAccess 和 icacls 输出。
访问成功截图或命令输出文本。
对应的 4624、4672、5140、5145 日志记录。

问答区里这类问题最容易遗漏的是“权限来源”。只证明能访问还不够，要说明为什么能访问：是本地管理员组、共享权限、NTFS ACL，还是 GPO 下发导致。只有定位到来源，修复才不会停留在临时改权限。

总结

授权内网渗透中发现 SMB 共享或管理共享可访问时，建议按“账号身份、组关系、共享权限、NTFS 权限、日志留痕、GPO 来源”逐项确认。结论要基于命令输出和日志，而不是主观判断。这样既能控制测试影响，也能给客户提供可执行的修复路径。

5小时前5小时

可以从“是否越权”和“是否留痕可复盘”两条线同时做，别只看能不能访问共享目录。一、确认 SMB 访问是否超出授权范围重点看这几类信息： 1. 当前账号实际获得的访问令牌在目标主机或跳板机上确认当前用户、组、特权：

whoami /user
whoami /groups
whoami /priv
net use

如果出现 Domain Admins、Backup Operators、Account Operators、Local Administrators 等非预期组，要重点核对授权范围。 2. 枚举共享和实际权限分开看共享可见不代表有权限，建议分别验证：

net view \\TARGET
net view \\TARGET /all

net use \\TARGET\C$ /user:DOMAIN\user
net use \\TARGET\ShareName /user:DOMAIN\user

注意 `C$`、`ADMIN$`、`IPC$` 这类管理共享。如果普通业务账号能访问 `C$` 或 `ADMIN$`，基本就要判定为高风险越权点，除非授权书里明确允许。 3. 看共享权限和 NTFS 权限的交集在目标机上检查：

Get-SmbShare
Get-SmbShareAccess -Name ShareName

icacls D:\SharePath

SMB 最终访问权限是“共享权限”和“NTFS 权限”取更严格的结果。常见误区是共享层给了 Everyone Read/Change，NTFS 层又给了 Domain Users Modify，导致普通域用户可写。 4. 检查是否通过本地管理员横向很多横向不是域权限导致，而是本地管理员密码复用。可以看目标机本地管理员组：

net localgroup administrators

或者 PowerShell：

Get-LocalGroupMember Administrators

如果某个域账号或域组被加进了大量机器本地管理员组，需要记录为横向扩散风险。二、留痕排查建议建议重点看 Windows 安全日志和 SMB 相关日志。 1. 登录事件目标机器安全日志： - 4624：成功登录 - 4625：失败登录 - 4634 / 4647：注销 - 4648：使用显式凭据登录 - 4672：分配了特殊权限 - 4776：NTLM 认证 - 4768 / 4769 / 4771：Kerberos 认证 SMB 横向一般会出现 4624，Logon Type 常见为： - Type 3：网络登录，SMB 常见 - Type 9：使用显式凭据，新凭据登录 - Type 10：远程交互登录，更多见于 RDP PowerShell 快速筛选：

Get-WinEvent -FilterHashtable @{
  LogName='Security'
  Id=4624,4625,4648,4672,4776
  StartTime=(Get-Date).AddHours(-12)
} | Select-Object TimeCreated,Id,@{n='User';e={$_.Properties[5].Value}},@{n='SourceIP';e={$_.Properties[18].Value}},Message

不同系统版本字段位置可能不同，最终还是以 Message 里的 Account Name、Workstation Name、Source Network Address 为准。 2. 文件共享访问事件默认不一定开启，需要提前开审计。组策略路径：

Computer Configuration
 -> Windows Settings
 -> Security Settings
 -> Advanced Audit Policy Configuration
 -> Object Access
 -> Audit File Share
 -> Audit Detailed File Share
 -> Audit File System

对应事件： - 5140：访问了网络共享 - 5145：检查了共享对象访问权限 - 4663：访问了具体文件对象可以这样查：

Get-WinEvent -FilterHashtable @{
  LogName='Security'
  Id=5140,5145,4663
  StartTime=(Get-Date).AddHours(-12)
} | Select-Object TimeCreated,Id,Message

5140 能看到访问了哪个共享，5145 更适合判断用户是否尝试访问具体路径以及访问结果。如果要证明“是否越权”，5145 比单纯 4624 更有价值。 3. SMB 客户端和服务端日志可以补充看这些日志：

Microsoft-Windows-SmbServer/Security
Microsoft-Windows-SmbServer/Audit
Microsoft-Windows-SMBClient/Connectivity
Microsoft-Windows-SMBClient/Security

查看是否启用：

wevtutil el | findstr /i smb

开启某个日志：

wevtutil sl Microsoft-Windows-SmbServer/Audit /e:true

三、判断是否越权的落地标准建议报告里不要只写“可访问 SMB”，而是按下面几个维度定性： 1. 授权范围该账号是否在测试授权账号清单内，目标主机是否在授权网段/资产清单内。 2. 访问深度只是 IPC$ 建连，还是能访问业务共享；是只读，还是可写、可删除、可覆盖。 3. 敏感共享是否访问了 `C$`、`ADMIN$`、`SYSVOL`、`NETLOGON`、备份目录、财务/人事/研发共享目录。 4. 凭据来源是正常授权凭据、弱口令、密码复用、缓存凭据、票据，还是本地管理员复用。 5. 留痕证据保留目标主机名、源 IP、账号、时间、共享名、访问结果、事件 ID、命令输出截图或日志导出。四、建议的最小化验证方式在授权渗透里验证 SMB 越权，尽量避免真实写入业务目录。可以先只做只读验证：

dir \\TARGET\ShareName
type \\TARGET\ShareName\test.txt

如果必须验证写权限，建议写入无害标记文件并立即删除，文件名带时间和测试编号：

echo smb_auth_test_%date%_%time% > \\TARGET\ShareName\smb_auth_test.txt
del \\TARGET\ShareName\smb_auth_test.txt

同时记录对应的 5145 / 4663 日志，方便证明“确实有写权限”，也便于蓝队复盘。最后补一句，SMB 横向排查里最容易漏的是“本地管理员组”和“共享权限 + NTFS 权限交集”。如果这两块没查清，很容易把配置问题误判成单次测试行为。

4小时前4小时

补一条比较实用的做法：不要只在客户端验证“我能不能进共享”，最好把 SMB 访问链路在服务端日志里对齐，这样后面定性越权会更稳。可以按“账号 → 来源主机 → 目标主机 → 共享名 → 文件路径 → 操作结果”这条线排。 1. 目标主机开 SMB 文件访问审计本地安全策略或 GPO：

计算机配置
  Windows 设置
    安全设置
      高级审核策略配置
        对象访问
          Audit File Share：成功、失败
          Audit Detailed File Share：成功、失败

对应命令可以参考：

auditpol /get /subcategory:"File Share"
auditpol /get /subcategory:"Detailed File Share"

auditpol /set /subcategory:"File Share" /success:enable /failure:enable
auditpol /set /subcategory:"Detailed File Share" /success:enable /failure:enable

然后重点看目标机 Security 日志：

5140：访问了网络共享对象
5145：检查了是否允许访问共享对象中的文件/目录
4624：登录成功，Logon Type 3 通常是网络登录
4634/4647：注销
4672：分配了特殊权限，出现高权限账号时要关注

2. 用事件把 SMB 访问还原出来 PowerShell 可以先粗筛一下：

Get-WinEvent -FilterHashtable @{
    LogName='Security'
    Id=5140,5145,4624,4672
    StartTime=(Get-Date).AddHours(-6)
} | Select-Object TimeCreated, Id, ProviderName, Message

如果日志量大，建议直接按目标账号或来源 IP 过滤。5145 里一般能看到类似字段：

Account Name
Source Address
Share Name
Relative Target Name
Accesses
Access Check Results

其中比较关键的是： - `Share Name`：是不是 `\\*\C$`、`\\*\ADMIN$`、业务共享等 - `Relative Target Name`：具体访问了哪个目录或文件 - `Accesses`：ReadData、WriteData、CreateFiles、Delete、WriteDAC 等 - `Access Check Results`：是允许还是拒绝这比单纯截图 `dir \\host\share` 更容易复盘。 3. 区分“授权访问”和“越权访问” 我一般会做一个简单矩阵，把实际日志和授权表对齐：

账号：DOMAIN\user1
来源：10.10.1.23
目标：FILE-SRV01
共享：\\FILE-SRV01\Finance
路径：2024\salary.xlsx
操作：ReadData
结果：Success
授权说明：该账号不在财务组，不应访问
结论：疑似越权，需核查 ACL/GPO/嵌套组

注意 AD 里经常不是账号直接授权，而是通过嵌套组拿到权限。可以查一下：

whoami /groups

Get-ADPrincipalGroupMembership user1 | Select-Object Name

Get-ADGroupMember "SomeGroup" -Recursive

如果发现用户因为历史遗留组、部门共享组、临时运维组获得访问权限，这类比单纯“密码泄露”更常见。 4. 查共享权限和 NTFS 权限是否叠加放大共享权限和 NTFS 权限要一起看，最终权限取更严格的一边，但很多环境会出现共享层 Everyone/Authenticated Users 给得过宽，靠 NTFS 控制，后期目录继承一乱就出问题。目标机上可以查：

net share

Get-SmbShare | Select-Object Name,Path,Description

Get-SmbShareAccess -Name ShareName

icacls "D:\ShareName"
icacls "D:\ShareName" /inheritance

重点关注： - `Everyone:(F)`、`Authenticated Users:(M)`、`Domain Users:(M/F)` - 非预期业务组有 Modify/FullControl - 子目录断开继承后权限失控 - 普通账号对共享目录有写入、删除、改 ACL 权限如果看到 `WriteDac`、`WriteOwner`、`FullControl`，风险要高于普通读取。 5. 注意 SMB 横向里的凭据使用痕迹如果是通过 SMB 触发横向，不一定只有文件访问。还要结合这些日志看：

4624 Logon Type 3：网络登录
4648：使用显式凭据登录
4672：特殊权限登录
7045：创建服务，常见于 psexec 类操作
4697：安装服务
4688：进程创建，需要已开启进程审计

比如访问 `ADMIN$` 后又出现服务创建，基本就不是单纯文件共享访问了，要单独归类成远程执行行为。 6. 建议提前做留痕约定授权测试里最好在操作前就约定： - 测试账号固定，不混用个人账号 - 来源 IP 固定 - 时间窗口固定 - 访问路径尽量使用约定测试目录 - 写入文件使用统一命名，比如 `pentest_yyyyMMdd_hostname.txt` - 不读取真实敏感文件，只验证权限边界这样后面服务端日志里很容易区分测试行为和真实异常行为，也方便客户侧复核。

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

注册帐户

立刻登录

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

粉丝

转到主题列表

没有会员查看此页面。

登录