授权内网渗透中如何确认横向登录边界并检查日志留痕

发布于5小时前5小时

背景

这个问题在问答中心里经常遇到：做授权内网渗透时，已经拿到一台普通域用户主机的访问权限，但不确定下一步哪些验证是允许的、哪些行为会越过权限边界，尤其是涉及 SMB、WinRM、RDP、计划任务和远程服务时，容易把“漏洞验证”做成“实际横向控制”。

下面按一次常见授权测试场景来整理：目标是验证某个域账号是否存在过度授权、是否能访问不该访问的共享目录或远程管理接口，同时检查蓝队侧能否通过日志定位行为。重点是边界确认、可复现排查、留痕检查和修复建议，不涉及规避监控或隐蔽持久化。

前提：所有操作应在书面授权范围内进行，明确测试网段、账号、时间窗口、允许的协议和禁止动作。不要在未授权主机上执行命令、创建服务、投递文件或修改配置。

问题定位

典型疑问可以拆成四个问题：

当前账号在域内到底拥有哪些组权限？
哪些主机允许该账号进行网络登录或远程管理登录？
验证访问边界时，如何做到“只验证、不扩大影响”？
相关行为会留下哪些 Windows 日志，应该如何给客户交付修复建议？

建议先确认三类信息：账号身份、目标资产范围、允许验证方式。比如只允许枚举 AD 信息和访问共享目录，就不要尝试远程命令执行；只允许验证 WinRM 开放性，就不要通过 WinRM 执行系统命令。

技术分析

在 Windows 域环境里，横向边界通常和以下配置有关：

Domain Admins、Enterprise Admins、本地 Administrators 组成员关系。
域策略中的 Allow log on through Remote Desktop Services、Deny log on locally、Deny log on through Remote Desktop Services。
主机本地组，如 Remote Management Users、Remote Desktop Users、Administrators。
SMB 共享权限与 NTFS 权限是否一致，是否存在 Everyone、Authenticated Users 过宽授权。
WinRM、RDP、SMB 等服务是否开放，且是否允许当前账号认证。

注意区分“端口开放”和“具备有效权限”。例如 5985 开放只说明 WinRM 服务可达，并不代表当前账号可以远程管理；445 可达也不代表可以读写敏感共享。

操作步骤

下面是一套偏保守的排查流程，适合问答中心里排查“账号权限是否越界”的问题。

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

在授权测试机或跳板机上确认当前账号信息，不要直接在生产服务器上做无关操作。

whoami /user
whoami /groups
whoami /priv
net user %USERNAME% /domain

如果允许使用 PowerShell 查询 AD，可以进一步查看账号直属组和递归组。递归组很关键，很多越权来自“套娃组”。

Import-Module ActiveDirectory
Get-ADUser test.user -Properties MemberOf | Select-Object -ExpandProperty MemberOf
Get-ADPrincipalGroupMembership test.user | Select-Object Name,DistinguishedName

2. 只做连通性和认证边界验证

对授权范围内的主机，先做端口和协议级验证，不要直接执行远程命令。示例仅用于判断服务是否可达：

$targets = @("10.10.20.11", "10.10.20.12", "10.10.20.13")
foreach ($t in $targets) {
    Test-NetConnection $t -Port 445  | Select-Object ComputerName,RemotePort,TcpTestSucceeded
    Test-NetConnection $t -Port 3389 | Select-Object ComputerName,RemotePort,TcpTestSucceeded
    Test-NetConnection $t -Port 5985 | Select-Object ComputerName,RemotePort,TcpTestSucceeded
}

如果需要验证 SMB 共享访问，建议只列目录，不写入、不删除、不上传测试文件，除非授权里明确允许。

net view \\10.10.20.11
net use \\10.10.20.11\share /user:DOMAIN\test.user *

如果认证成功但不需要进一步访问文件内容，可以立即断开连接，减少影响面。

net use \\10.10.20.11\share /delete

3. 检查本地管理员和远程登录边界

如果授权允许检查目标主机本地组成员，可以通过管理员提供的只读审计账号或集中管理平台导出。不要为了验证而添加账号到本地管理员组。

Get-LocalGroupMember -Group "Administrators"
Get-LocalGroupMember -Group "Remote Desktop Users"
Get-LocalGroupMember -Group "Remote Management Users"

在域控或管理机上，可以查询组策略中远程登录相关配置。重点看是否把普通业务组加入了远程桌面或本地管理员。

gpresult /h C:\Temp\gp.html
secedit /export /cfg C:\Temp\secpol.cfg
findstr /i "SeRemoteInteractiveLogonRight SeDenyRemoteInteractiveLogonRight SeNetworkLogonRight" C:\Temp\secpol.cfg

日志留痕检查

授权验证完成后，要能回答“做了什么、在哪些主机留下了什么日志”。常见事件如下：

行为	常见日志位置	事件 ID	说明
网络登录 SMB	Security	4624	Logon Type 3，常见于访问共享、远程服务认证
登录失败	Security	4625	可用于发现口令错误、权限不足、账号被拒绝
RDP 登录	Security / TerminalServices	4624 / 1149	通常为 Logon Type 10 或相关远程交互登录记录
特权账号登录	Security	4672	账号被授予特殊权限时出现
访问共享对象	Security	5140 / 5145	需要开启对象访问审计才能更完整

可以在目标主机或日志平台中按账号和时间窗口筛选。下面示例用于本机筛选最近一天内指定账号的登录事件：

$user = "test.user"
$start = (Get-Date).AddDays(-1)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624,4625,4672; StartTime=$start} |
Where-Object { $_.Message -match $user } |
Select-Object TimeCreated, Id, ProviderName, Message

如果开启了 PowerShell 日志，还应检查：

Microsoft-Windows-PowerShell/Operational 中的 4103、4104。
Windows PowerShell 日志中的命令执行记录。
EDR 或堡垒机中的会话审计记录。

风险与修复建议

根据排查结果，常见问题和建议如下：

普通域用户可访问敏感共享：检查共享权限和 NTFS 权限，避免 Everyone、Domain Users、Authenticated Users 拥有写入或读取敏感目录权限。
业务组被加入本地管理员：按最小权限原则拆分运维组、业务组、审计组。对服务器本地管理员进行集中清理。
WinRM 对全网开放：限制 5985/5986 访问来源，仅允许堡垒机、管理网段访问；启用 HTTPS WinRM 时注意证书管理。
RDP 可被普通用户登录：收敛 Remote Desktop Users 成员，结合 MFA、堡垒机和登录时间策略。
日志不足：开启登录审计、对象访问审计和 PowerShell Script Block Logging，但要评估日志量并接入集中日志平台。
账号复用严重：服务账号、运维账号、个人账号分离；服务账号禁止交互式登录；定期轮换密码。

一个比较实用的域策略方向是：普通用户默认只能登录自己的办公终端；服务器远程管理只允许指定运维组从堡垒机来源访问；高权限账号禁止登录普通办公终端，降低凭据暴露风险。

总结

在问答中心讨论这类授权内网渗透问题，建议把重点放在“如何确认权限边界”和“如何形成可交付证据”。不要一上来就追求横向执行，很多时候只需要证明某个账号能够认证、能够访问不该访问的共享，风险就已经成立。

比较稳妥的做法是：先确认授权范围，再做身份和组关系排查，随后进行协议连通性与最小化访问验证，最后结合 4624、4625、4672、5140、5145 等日志给出证据链和修复建议。这样既能满足漏洞验证需求，也能控制对生产环境的影响。

5小时前5小时

建议把“边界确认”和“留痕核对”分开做，不要只靠能不能登录来判断横向范围。授权内网里我一般这样处理： 1. 先确认授权边界重点看账号、网段、系统类型、登录协议四个维度： - 哪些账号允许用于横向：域账号、本地管理员、服务账号是否都包含 - 哪些资产在范围内：IP 段、主机清单、业务系统清单是否一致 - 哪些协议允许：RDP、SMB、WinRM、SSH、数据库连接是否被授权 - 是否允许凭据复用、票据使用、远程执行命令如果授权文档只写了“内网渗透”，最好补一份操作矩阵，比如：

资产范围：10.10.0.0/16，仅限服务器网段 10.10.20.0/24、10.10.30.0/24
允许账号：test_redteam，禁止使用生产管理员账号
允许协议：RDP、SMB、WinRM
禁止动作：批量密码喷洒、域控高风险操作、生产库写操作
验证方式：仅做登录验证，不落地持久化组件

否则后面做横向登录，很容易出现“技术上能到，但合规上越界”的问题。 2. 横向登录建议做最小化验证不要直接扫全网登录。可以先从 CMDB、AD、DNS、EDR 控制台导出目标，再按授权范围过滤。 Windows 域环境可以先看当前账号能访问哪些主机：

whoami /all
net user %USERNAME% /domain
net group "Domain Admins" /domain
net group "Remote Desktop Users" /domain
net group "Administrators" /domain

查目标主机是否允许远程管理：

Test-NetConnection 10.10.20.15 -Port 3389
Test-NetConnection 10.10.20.15 -Port 445
Test-NetConnection 10.10.20.15 -Port 5985

WinRM 最小化验证可以用：

Test-WSMan 10.10.20.15

如果只是确认登录边界，不建议直接执行复杂命令。可以用低影响命令验证身份和主机名：

hostname
whoami
ipconfig /all

SSH 场景也一样，优先用只读命令：

ssh [email protected] 'hostname; whoami; id; ip addr'

3. 日志留痕要按协议分别检查 Windows 横向登录主要看安全日志和远程服务日志。常见事件： - 4624：登录成功 - 4625：登录失败 - 4634 / 4647：注销 - 4648：使用显式凭据登录 - 4672：特殊权限登录 - 4776：NTLM 认证 - 4768 / 4769 / 4771：Kerberos 相关 - 1149：RDP 认证成功，位于 TerminalServices 日志 - 7045：服务创建，常见于 PsExec 类行为 - 4688：进程创建，需要开启审计命令行才有价值本机快速查安全日志：

Get-WinEvent -FilterHashtable @{
  LogName='Security'
  Id=4624,4625,4648,4672,4776,4768,4769
  StartTime=(Get-Date).AddHours(-4)
} | Select-Object TimeCreated,Id,ProviderName,Message

筛选某个源 IP：

Get-WinEvent -FilterHashtable @{
  LogName='Security'
  Id=4624,4625
  StartTime=(Get-Date).AddHours(-4)
} | Where-Object {
  $_.Message -match '10\.10\.20\.100'
} | Select-Object TimeCreated,Id,Message

RDP 日志：

Get-WinEvent -LogName 'Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational' |
Where-Object {$_.Id -eq 1149 -and $_.TimeCreated -gt (Get-Date).AddHours(-4)} |
Select-Object TimeCreated,Id,Message

SMB 登录一般关注 4624 中的 LogonType： - 3：网络登录，常见 SMB、远程服务访问 - 10：RDP - 2：本地交互登录 - 5：服务登录 - 9：NewCredentials，常见 runas /netonly 可以把 4624 的 LogonType 拉出来看：

Get-WinEvent -FilterHashtable @{
  LogName='Security'
  Id=4624
  StartTime=(Get-Date).AddHours(-4)
} | ForEach-Object {
  $xml = [xml]$_.ToXml()
  [PSCustomObject]@{
    Time = $_.TimeCreated
    LogonType = ($xml.Event.EventData.Data | Where-Object {$_.Name -eq 'LogonType'}).'#text'
    TargetUser = ($xml.Event.EventData.Data | Where-Object {$_.Name -eq 'TargetUserName'}).'#text'
    IpAddress = ($xml.Event.EventData.Data | Where-Object {$_.Name -eq 'IpAddress'}).'#text'
    Workstation = ($xml.Event.EventData.Data | Where-Object {$_.Name -eq 'WorkstationName'}).'#text'
  }
}

4. Linux 侧检查 SSH 登录主要看：

# Debian/Ubuntu
grep -E "Accepted|Failed|session opened|session closed" /var/log/auth.log

# RHEL/CentOS
grep -E "Accepted|Failed|session opened|session closed" /var/log/secure

last -a
lastb -a
journalctl -u sshd --since "4 hours ago"

如果用了 sudo，再看：

grep sudo /var/log/auth.log
journalctl _COMM=sudo --since "4 hours ago"

5. 建议保留一份操作对账表每次横向登录都记录：

时间：
源主机：
源账号：
目标主机：
协议：
验证命令：
预期日志：
实际日志事件 ID：
是否越界：
备注：

这样后面和蓝队、运维、安全平台对日志时比较清楚。尤其是 4624、4648、4672、1149、7045 这几个点，能较好还原一次横向登录是否真实发生、使用了什么方式、有没有触发高风险行为。另外提醒一点：如果目标接了 EDR / SIEM，最好提前和防守侧约定测试窗口和标识，比如使用固定源 IP、固定测试账号、固定命令前缀。否则单纯从终端日志看到了，但平台侧规则没触发，最后很难判断是日志采集问题、规则问题，还是操作路径没有覆盖到。

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

注册帐户

立刻登录

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

粉丝

转到主题列表

没有会员查看此页面。

登录