发布于10月9日10月9日 背景最近在一次授权内网渗透测试里，入口点是一台已纳入域的 Windows 业务终端。测试目标不是“拿多少机器”，而是验证域内权限边界、弱口令/凭据复用风险、SMB 横向访问面，以及蓝队日志是否能完整还原攻击链。环境大致如下：域：corp.local网段：10.10.20.0/24入口主机：WIN10-OPS，普通域用户权限域控：DC01，Windows Server 2019重点验证：SMB 管理共享、远程服务创建、登录事件、凭据复用、横向移动留痕说明：本文只讨论授权渗透测试中的验证与排查方法，重点是攻防链路、日志定位和修复建议。不要在未授权环境执行。问题定位初始阶段拿到一组普通域账号后，发现该账号对部分服务器存在异常访问权限。常见情况有两类：域用户被加入了某些服务器本地 Administrators 组多台服务器复用同一组本地管理员口令，导致凭据横向可用在渗透测试里，我一般先不急着执行远程命令，而是先做三件事：确认账号权限边界：能访问哪些主机、哪些共享、是否有管理权限控制验证动作：优先使用只读、低影响命令，避免影响业务同步记录日志点：方便后续和蓝队核对告警与事件链技术分析SMB 横向验证里，常见有效路径是：通过 445 端口确认主机存活和 SMB 服务状态使用已授权凭据测试 IPC$、ADMIN$、C$ 等共享访问如果具备管理员权限，进一步验证远程服务创建或计划任务执行能力在目标主机与域控上回溯登录、服务创建、进程启动、共享访问日志需要关注的是，很多横向行为即使没有成功执行命令，也会留下认证痕迹。例如：目标主机安全日志中的 4624 / 4625域控上的 4768 / 4769 / 4771 / 4776目标主机系统日志中的 7045 服务创建启用对象访问审计后可见的 5140 / 5145 共享访问Sysmon 中的 1 进程创建、3 网络连接、11 文件创建操作步骤下面是一套比较克制的验证流程，适合授权测试时使用。1. 枚举 SMB 存活与基础信息先确认 445 暴露面，不直接爆破，不做大流量扫描。nmap -Pn -p445 --open 10.10.20.0/24 -oA smb_445_scan如果环境对扫描敏感，可以降低速率：nmap -Pn -p445 --open --max-rate 50 10.10.20.0/24 -oA smb_445_slow2. 使用授权账号验证共享访问示例使用 crackmapexec 进行登录验证和共享枚举。重点看哪些机器返回 Pwn3d 或可访问 ADMIN$ / C$。crackmapexec smb 10.10.20.0/24 -d corp.local -u test.user -p 'Password123!' --shares如果不希望工具自动做过多动作，也可以用 smbclient 单点验证：smbclient -L //10.10.20.35 -U 'corp.local/test.user%Password123!'看到 ADMIN$ 或 C$ 并不等于一定可以远程执行命令，但通常说明权限边界已经存在问题，需要进一步确认该用户在目标主机本地组中的身份。3. 验证本地管理员权限可通过远程查询本地 Administrators 组。Windows 环境下可使用 net 命令：net localgroup administrators /domain对目标主机单点验证时，可以使用 PowerShell 远程查询，但前提是 WinRM 已开启且授权范围允许：$cred = Get-Credential corp.local\test.user Invoke-Command -ComputerName 10.10.20.35 -Credential $cred -ScriptBlock { net localgroup administrators }如果 WinRM 未开，不建议为了测试强行开启服务。渗透验证应尽量不改变目标配置。4. 控制远程执行验证如果客户明确允许验证远程命令执行能力，我通常只执行无破坏的短命令，例如 hostname、whoami、ipconfig，并约定时间窗口。crackmapexec smb 10.10.20.35 -d corp.local -u test.user -p 'Password123!' -x "whoami && hostname"该行为通常会触发远程服务创建或类似执行痕迹，蓝队侧应该能在目标主机看到对应事件。日志留痕与排查方法1. 目标主机安全日志横向登录最关键的是 4624。SMB 常见登录类型为 3，即网络登录。Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624; StartTime=(Get-Date).AddHours(-6)} | Where-Object { $_.Properties[8].Value -eq 3 } | Select-Object TimeCreated, Id, @{n='Account';e={$_.Properties[5].Value}}, @{n='SourceIP';e={$_.Properties[18].Value}}, @{n='LogonType';e={$_.Properties[8].Value}}常见字段关注：Logon Type：3 表示网络登录Account Name：发起登录的账号Source Network Address：来源 IPAuthentication Package：NTLM 或 Kerberos2. 失败登录排查如果存在密码喷洒或错误凭据验证，会出现 4625。授权测试中不建议进行高频尝试，避免触发锁定策略。Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddHours(-6)} | Select-Object TimeCreated, @{n='Account';e={$_.Properties[5].Value}}, @{n='SourceIP';e={$_.Properties[19].Value}}, @{n='Status';e={$_.Properties[7].Value}}3. 远程服务创建事件如果使用了基于服务创建的远程执行方式，系统日志中通常会出现 7045。Get-WinEvent -FilterHashtable @{LogName='System'; Id=7045; StartTime=(Get-Date).AddHours(-6)} | Select-Object TimeCreated, ProviderName, Message重点看：Service Name 是否随机或异常Service File Name 是否指向 ADMIN$、Temp 或异常路径创建时间是否与测试动作匹配4. 共享访问事件如果启用了对象访问审计，可以看 5140 / 5145。Get-WinEvent -FilterHashtable @{LogName='Security'; Id=5140; StartTime=(Get-Date).AddHours(-6)} | Select-Object TimeCreated, @{n='Account';e={$_.Properties[1].Value}}, @{n='ShareName';e={$_.Properties[6].Value}}, @{n='SourceIP';e={$_.Properties[5].Value}}5145 可以进一步看到访问了什么相对路径、权限掩码和访问结果，对判断 ADMIN$ 写入特别有用。5. 域控侧认证日志如果使用域账号访问 SMB，域控上一般可以看到 Kerberos 或 NTLM 相关事件：4768：请求 TGT4769：请求服务票据，常见服务名 cifs/hostname4771：Kerberos 预认证失败4776：NTLM 认证Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4769; StartTime=(Get-Date).AddHours(-6)} | Where-Object { $_.Properties[2].Value -like 'cifs/*' } | Select-Object TimeCreated, @{n='User';e={$_.Properties[0].Value}}, @{n='Service';e={$_.Properties[2].Value}}, @{n='ClientIP';e={$_.Properties[6].Value}}检测规则思路蓝队可以把以下条件作为告警线索，不建议单点定罪，要结合上下文：普通域用户在短时间内访问多台主机的 ADMIN$ 或 C$同一来源 IP 对多个目标产生 4624 Type 3 登录4624 Type 3 后紧跟 7045 服务创建4769 中出现大量 cifs/ 主机服务票据请求非运维时间段出现远程服务创建或远程命令执行痕迹一个简单的关联逻辑是：源 IP 相同、账号相同、5 分钟内同时出现 4624 Type 3 和 7045，应优先排查。风险与修复建议1. 清理本地管理员权限不要把普通域用户或大范围域组加入服务器本地 Administrators。建议按业务系统拆分最小权限组，并定期导出核查。Get-LocalGroupMember Administrators域内可以通过 GPO 或脚本批量核查本地管理员成员，发现 Domain Users、Authenticated Users、业务普通组进入本地管理员时应立即整改。2. 禁止本地管理员口令复用推荐部署 Windows LAPS 或新版 Windows LAPS，确保每台机器本地管理员密码唯一且定期轮换。这样即使单台机器凭据泄露，也难以横向扩散。3. 收敛 SMB 管理面限制 445 端口访问范围，只允许堡垒机、运维网段、管理服务器访问普通办公终端之间禁止互访 445服务器区按业务和管理面拆分 ACL禁用不必要的 ADMIN$ 使用场景，至少做到来源可控4. 强化认证与审计策略开启账号锁定策略，但阈值要结合业务避免误伤开启 Kerberos 与 NTLM 审计，逐步减少 NTLM 使用开启命令行审计和 PowerShell 日志部署 Sysmon，重点采集进程、网络连接、文件创建和服务创建建议的 Sysmon 关注项：Event ID 1：异常远程执行进程，例如 cmd.exe /c、powershell.exeEvent ID 3：来自非管理网段的 445/135/5985 连接Event ID 11：ADMIN$、Temp 目录下异常文件写入Event ID 13：可疑注册表修改5. 渗透测试后的闭环验证修复完成后不要只看配置是否改了，应重新验证：原账号是否仍可访问 ADMIN$ / C$原来源 IP 是否还能访问目标 445远程命令执行是否被阻断蓝队是否能在日志平台关联到测试动作告警是否有明确字段：账号、源 IP、目标主机、事件 ID、时间线总结内网渗透里的 SMB 横向并不复杂，真正容易出问题的是权限边界长期失控、本地管理员口令复用、日志没有关联起来。授权测试时应控制动作强度，明确记录每一步时间点和目标，方便蓝队复盘。比较有效的防护思路也很直接：最小化本地管理员权限、LAPS 管理本地口令、限制 445 横向访问、完善 4624/4625/4769/7045/5140/5145 等日志采集，并把登录、共享访问、服务创建放在同一条时间线上看。这样即使攻击链没有完全阻断，也能更早发现并压缩影响范围。 服务器、云资产与权限边界梳理示意
10月9日10月9日 这个案例如果重点是“SMB 横向验证 + 留痕 + 修复闭环”，建议把复盘做成可验证的证据链，而不是只记录是否能连通。 1. 横向验证阶段建议补充最小化验证项 授权场景下验证 SMB 横向时，尽量避免用“拿到交互式 shell”作为唯一判断标准，可以拆成几类证据： 445 端口连通性 认证是否成功 是否具备管理共享访问权限 是否能远程创建服务 / 计划任务 是否触发目标侧安全日志 Windows 侧可以用内置命令做低侵入验证： net use \\10.0.0.23\IPC$ /user:DOMAIN\user password net view \\10.0.0.23 dir \\10.0.0.23\C$ sc.exe \\10.0.0.23 query schtasks /query /s 10.0.0.23 /u DOMAIN\user /p password 这里要特别区分： IPC$ 成功：只能说明认证链路和基础权限成立 C$ 可访问：通常意味着本地管理员或等价权限 sc.exe 可远程操作：风险等级更高，基本具备远程执行条件 2. 日志留痕建议按事件 ID 串起来 SMB 横向相关日志不要只看 4624，最好把源主机、目标主机和域控三边日志对齐。常见事件可以重点关注： 4624：登录成功，重点看 Logon Type 3 4625：登录失败，可用于发现密码喷洒或口令试探 4672：特殊权限登录，管理员权限常见 5140：访问网络共享 5145：详细文件共享访问 7045：新服务安装，常见于远程服务执行 4698：计划任务创建 4768 / 4769 / 4771：Kerberos 认证链路，主要看域控 4776：NTLM 认证，定位 NTLM 横向比较有用 目标主机上可以这样快速拉取相关日志： wevtutil qe Security /q:"*[System[(EventID=4624 or EventID=4625 or EventID=4672 or EventID=5140 or EventID=5145)]]" /f:text /c:50 wevtutil qe System /q:"*[System[(EventID=7045)]]" /f:text /c:20 wevtutil qe Security /q:"*[System[(EventID=4698)]]" /f:text /c:20 如果环境开了 PowerShell 日志，还可以补一下： wevtutil qe Microsoft-Windows-PowerShell/Operational /f:text /c:50 3. 修复闭环要落到“验证前后对比” 修复建议不要只写“关闭 SMB”这种大而化之的结论。内网里很多业务还依赖 SMB，实际闭环可以按优先级来： 禁用 SMBv1 限制 445 横向访问范围，只允许文件服务器、运维跳板机等必要节点 清理本地管理员组里的域账号 部署 LAPS / Windows LAPS，避免本地管理员密码复用 关闭不必要的管理共享访问或限制远程管理来源 开启 SMB 签名，降低中间人和中继风险 对域管、高权限账号禁止在普通终端登录 几条可直接检查的命令： # 查看 SMBv1 状态 Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol # 禁用 SMBv1 Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart # 查看 SMB 配置 Get-SmbServerConfiguration | Select EnableSMB1Protocol, EnableSMB2Protocol, RequireSecuritySignature, EnableSecuritySignature # 启用 SMB 签名要求 Set-SmbServerConfiguration -RequireSecuritySignature $true -Force 防火墙侧可以做源地址限制，例如只允许运维网段访问 445： New-NetFirewallRule ` -DisplayName "Allow SMB from Admin Subnet" ` -Direction Inbound ` -Protocol TCP ` -LocalPort 445 ` -RemoteAddress 10.10.10.0/24 ` -Action Allow New-NetFirewallRule ` -DisplayName "Block SMB from Others" ` -Direction Inbound ` -Protocol TCP ` -LocalPort 445 ` -Action Block 注意规则顺序和现有 GPO 是否会覆盖，本地改完最好在组策略层固化。 4. 建议在报告中补一个“复测矩阵” 闭环最容易被忽略的是复测。可以做一个简单矩阵： 源主机 目标主机 账号 修复前结果 修复后结果 对应日志 普通办公终端 服务器 A 普通域账号 IPC$ 成功 失败 4625 / 防火墙日志 运维跳板机 服务器 A 授权运维账号 C$ 成功 成功 4624 Type 3、5140 普通终端 服务器 A 本地管理员复用账号 C$ 成功 失败 4625 / 4776 这样可以证明修复不是“一刀切断业务”，而是把横向面收敛到授权路径。 整体来看，这类授权内网项目最有价值的不是证明 SMB 能打通，而是把“权限复用路径、日志证据、整改动作、复测结果”串起来。这样后续无论给安全团队还是运维团队，都能直接落地。
10月10日10月10日 还有一个点建议补上：把“目标侧到底留下了什么”按日志源拆开，不然修复闭环时容易只看到攻击机侧命令记录，看不到蓝队能不能稳定检出。 SMB 横向验证时，Windows 目标机上至少可以对照这些事件： 4624：登录成功，重点看 Logon Type，SMB 常见是 3，并记录来源 IP、账号、认证包。 4625：登录失败，适合验证密码喷洒/错误凭据是否被发现。 4672：特殊权限登录，管理员类账号很关键。 5140：访问共享对象，比如 \\*\IPC$、\\*\C$。 5145：详细文件共享访问，需要开启对象访问审计后更有价值。 7045：创建服务，若用 sc.exe 做远程服务验证，这条基本要重点关注。 4698：创建计划任务，适合对应 schtasks 远程验证。 4688：进程创建日志，如果启用了进程命令行审计，可以看到服务或任务拉起的命令。 可以在目标机上用 PowerShell 快速拉一段时间窗口内的证据，避免事后只靠截图： $start = (Get-Date).AddHours(-2) Get-WinEvent -FilterHashtable @{ LogName='Security' Id=4624,4625,4672,5140,5145,4698,4688 StartTime=$start } | Select-Object TimeCreated, Id, ProviderName, Message | Export-Csv C:\Temp\smb_lateral_security_events.csv -NoTypeInformation -Encoding UTF8 Get-WinEvent -FilterHashtable @{ LogName='System' Id=7045 StartTime=$start } | Select-Object TimeCreated, Id, ProviderName, Message | Export-Csv C:\Temp\smb_lateral_system_events.csv -NoTypeInformation -Encoding UTF8 如果环境里已经接入了域控或 SIEM，也建议把域控侧事件一起看。很多时候目标机能看到 4624，但账号认证链路在 DC 上更完整，例如 Kerberos/NTLM 认证行为、失败原因、来源主机名是否匹配等。 修复闭环部分可以做得更落地一些，不只是“关闭 SMB”： 确认管理共享访问是否真的需要跨网段开放，至少用防火墙限制 445/TCP 到运维跳板机或管理网段。 本地管理员密码要用 LAPS / Windows LAPS 管理，避免一台机器管理员口令横向通用。 普通域账号不要进入本地 Administrators，单独梳理 GPO、登录脚本、历史加域模板。 启用“拒绝从网络访问这台计算机”策略，把高权限账号限制在必要主机上。 远程服务创建、计划任务创建要做告警，特别是 7045、4698 这类事件。 GPO 上可以重点看这些位置： Computer Configuration └─ Windows Settings └─ Security Settings └─ Local Policies ├─ User Rights Assignment │ ├─ Deny access to this computer from the network │ ├─ Deny log on as a service │ └─ Deny log on as a batch job └─ Security Options ├─ Network access: Sharing and security model for local accounts └─ Microsoft network server: Digitally sign communications 我一般会在报告里加一个小表，把每一步验证和对应日志绑定起来，例如： 验证动作 预期结果 目标侧日志 风险判断 修复动作 net use \\host\IPC$ 认证成功 4624、5140 账号可进行网络登录 限制账号网络登录范围 dir \\host\C$ 可列目录 4624、5140、5145 具备管理共享访问 收敛本地管理员权限 sc \\host query 可远程查询服务 4624，必要时结合 7045 具备服务控制权限 限制 445/RPC，仅允许运维源 schtasks /query /s host 可查询任务 4624，创建时看 4698 可能具备任务远程操作面 审计任务创建并告警 这样复盘时就比较清楚：不是单纯证明“我能横向”，而是能回答三个问题：权限边界在哪里、日志是否覆盖、修复后同样路径是否失效。这个对授权测试和后续整改验收都更有说服力。
创建帐户或登录后发表意见