kerberos

在Kerberos协议中主要是有三个角色的存在：

  1. 访问服务的Client(以下表述为Client 或者用户)

  2. 提供服务的Server(以下表述为服务)

  3. KDC（Key Distribution Center）密钥分发中心

    步骤

    1. 1. AS_REQ: Client向KDC发起AS_REQ,请求凭据是Client hash加密的时间戳
2. AS_REP: KDC使用Client hash进行解密，如果结果正确就返回用krbtgt hash加密的TGT票据，TGT里面包含PAC,PAC包含Client的sid，Client所在的组。
3. TGS_REQ: Client凭借TGT票据向KDC发起针对特定服务的TGS_REQ请求
4. TGS_REP: KDC使用krbtgt hash进行解密，如果结果正确，就返回用服务hash 加密的TGS票据(这一步不管用户有没有访问服务的权限，只要TGT正确，就返回TGS票据)
5. AP_REQ: Client拿着TGS票据去请求服务
6. AP_REP: 服务使用自己的hash解密TGS票据。如果解密正确，就拿着PAC去KDC那边问Client有没有访问权限，域控解密PAC。获取Client的sid，以及所在的组，再根据该服务的ACL，判断Client是否有访问服务的权限。


            

      ## AS_REQ & AS_REP

      ### AS_REQ

      ###  pvno

      kerberos 版本号

      ###  msg-type

      类型，AS_REQ对应的就是KRB_AS_REQ(0x0a)

      ###  PA_DATA

      主要是一些认证信息。一个列表，包含若干个认证消息用于认证，我们也可以Authenticator。每个认证消息有type和value。



      在AS_REQ主要用到的是时间戳（ENC_TIMESTAMP）和PA_PAC_REQUEST

      ENC_TIMESTAMP 

      他是用于预认证，通过用户的hash加密时间戳作为值发送给AS,AS第一时间找到AD确认有此用户的hash，然后会对这个hash进行解密，且时间戳在一定范围内，即可通过认证

      PA_PAC_REQUEST

      启用PAC支持的扩展PAC（Privilege Attribute Certificate）PA_PAC_REQUEST是Kerberos协议中的一个预认证选项，用于请求在TGT票据的PAC（特权属性证书）中添加PAC_REQUESTOR结构体，该结构体记录了原始请求者的身份标识（SID），以防止攻击者伪造黄金票据

      ### REQ_BODY

      cname 客户端的名字

      - ```
        PrincipalName 类型。PrincipalName包含type和value。
        
        - KRB_NT_PRINCIPAL = 1 means just the name of the principal 如dailker
        - KRB_NT_SRV_INST = 2 service and other unique instance (krbtgt) 如krbtgt，cifs
        - KRB_NT_ENTERPRISE_PRINCIPAL = 10 如 user@domain.com

sname 服务段名字

PrincipalName 类型

在AS_REQ里面sname是krbtgt，类型是KRB_NT_SRV_INST

  • realm

    域名

  • from

    发送时间

  • till

    到期时间，rubeus和kekeo都是20370913024805Z，这个可以作为特征来检测工具。

  • nonce

    随机生成的一个数kekeo/mimikatz nonce是12381973，rubeus nonce是1818848256，这个也可以用来作为特征检测工具。

    AS_REP

1. msg-type

AS_REQ的响应body对应的就是KRB_AS_REP(0x0b)

2. crealm

域名

3. cname

用户名

4. ticket

这个ticket用于TGS_REQ的认证。是加密的，用户不可读取里面的内容。在AS_REQ请求里面是，是使用krbtgt的hash进行加密的，因此如果我们拥有krbtgt的hash就可以自己制作一个ticket，既黄金票据。

5. enc_part

这部分是可以解密的，key是用户hash，解密后得到Encryptionkey，Encryptionkey里面最重要的字段是session key，作为下阶段的认证密钥

TGT

凭据里面最核心的东西是session-key和加密的ticket。

相关安全问题

哈希传递攻击Pass The Hash/Key

一句话解释下就是说在登录的时候进行验证拿windows举例 NTML只看你的HASH,不认你的明文密码，那么攻击者只要拿到HASH即可登录验证成功，其他操作系统也是可以但是Windows系统是最好拿的，为什么呢？因为HASH存储在各个地方比如说LSASS（电脑内存里），SAM系统文件,域控的数据库当中（ntds.dit），并且只要你不改密码 他就长期有效，并且再安装域环境的时候，使用都是相同管理员的相同密码，在域中，若域管理员登录用与管理员账户登录过某台主机，则HASH就会被记录在登录过的主机中，我们就有机会获得其中的hash,进行对相同域的其他主机的一个横向渗透，如果在不支持rc4加密方式的时候，就可以使用ptk（是攻击者利用AES加密密钥直接登录其他系统）

用户名枚举

就是根据用户名存在和不存在返回的包的清苦按来进行判断用户名的存在，如果用户名存在但是密码错误返回KDC_ERR_PREAUTH_FAILED，如果用户名不存在就会返回KDC_ERR_C_PRINCIPAL_UNKNOWN，那么攻击者就可以通过改变cname的值进行用户名枚举，在域内没有域账号的情况下进行枚举，有账号的情况下可以直接进行LDAP查询即可

Password Spraying

同样上面讲的密码错误的情况下会返回KDC_ERR_PREAUTH_FAILED，通过脚本可以对弱密码进行一个爆破，但是在实践中，许多渗透测试人员和攻击者通常都会使用一种被称为“密码喷洒（Password Spraying）”的技术来进行测试和攻击因为针对同一个用户的连续密码猜测会导致帐户被锁定。所以只有对所有用户同时执行特定的密码登录尝试，才能增加破解的概率，消除帐户被锁定的概率。普通的爆破就是用户名固定，爆破密码，但是密码喷洒，是用固定的密码去跑用户名。

AS-REPRoasting

PA_DATA这个字段的值是可选的，如果不填写padata，意思就是想让KDC不经过认证将这个账户（administrator）的TGT返回，即使没有提供账户密码

这里漏洞的关键就是管理员关闭了预认证的这个选项，那么攻击者只要扫描域内所有用户哪些用户没有启动域认证的选项，然后像域控制器的88端口发送AS_REQ请求提取 enc-part 下的 cipher 字段。这部分是用用户密码哈希加密的会话密钥将提取的 cipher 值拼接成 **Kerberos 5 AS-REP etype 23**（Hashcat 的 18200 模式专用格式），接着通过攻击例如hashcat进行离线爆破

黄金票据

黄金票据是伪造票据授予票据（TGT），也被称为认证票据在AS_REP里面的ticket的encpart是使用krbtgt的hash进行加密的，如果我们拥有krbtgt的hash，就可以给我们自己签发任意用户的TGT票据，这个票据也被称为黄金票据。

TGS_REQ & TGS_REP

TGS_REQ

1. msg-type

类型，TGS_REQ对应的就是KRB_TGS_REQ(0x0c)

2. PA-DATA

正常的TGS_REQ的请求需要用到有

  • AP_REQ

这个是TGS_REQ必须携带的部分，这部分会携带AS_REP里面获取到的TGT票据，就放在这个结构体里面。

KDC校验TGT票据，如果票据正确，就返回TGS票据。

PA_FOR_USER

类型是S4U2SELF

值是一个唯一的标识符，该标识符指示用户的身份。该唯一标识符由用户名和域名组成。

S4U2proxy 必须扩展PA_FOR_USER结构，指定服务代表某个用户(图片里面是administrator)去请求针对服务自身的kerberos服务票据。

PA_PAC_OPTIONS

类型是 PA_PAC_OPTIONS

值是以下flag的组合

– Claims(0)

– Branch Aware(1)

– Forward to Full DC(2)

– Resource-based Constrained Delegation (3)

微软的MS-SFU 2.2.5， S4U2proxy 必须扩展PA-PAC-OPTIONS结构。

如果是基于资源的约束委派，就需要指定Resource-based Constrained Delegation位。

REQ_BODY

sname

这个是要请求的服务，TGS_REP获得的ticket是用该服务用户的hash进行加密的。有个比较有意思的特性是，如果指定的服务是krbtgt，那么拿到的TGS票据是可以当做TGT票据用的。

附加票据，在S4U2proxy请求里面，既需要正常的TGT，也需要S4U2self阶段获取到的TGS，那么这个TGS就添加到AddtionTicket里面。

TGS_REP

1. msg-type

AS_REQ的响应body对应的就是KRB_TGS_REQ(0x0d)

2. ticket

这个ticket用于AP_REQ的认证。其中里面的enc_part是加密的，用户不可读取里面的内容。在AS_REQ请求里面是，是使用krbtgt的hash进行加密的，而在TGS_REQ里面是使用要请求的服务的hash加密的。因此如果我们拥有服务的hash就可以自己制作一个ticket，既白银票据。

3.enc_part

这部分是可以解密的，key是上一轮AS_REP里面返回的session_key,也就是导入凭据里面的 session_key，解密后得到encryptionkey，encryptionkey这个结构里面最重要的字段也是session_key(但是这个session_key 不同于上一轮里面的session_key)，用来作为作为下阶段的认证密钥。

S4U2SELF