Kerberos篇

Kerberos篇

认证流程

在该协议中有三个角色存在，分别是

1.client（访问服务的用户）

2.server（用来提供服务端）

3.KDC（是密钥分发中心）

Kerberos认证结合起来是这样的

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数据包

#数据包
Kerberos
    Record Mark: 299 bytes
        0... .... .... .... .... .... .... .... = Reserved: Not set
        .000 0000 0000 0000 0000 0001 0010 1011 = Record Length: 299
    as-req
        pvno: 5
        msg-type: krb-as-req (10)
        padata: 2 items
            PA-DATA pA-ENC-TIMESTAMP
                padata-type: pA-ENC-TIMESTAMP (2)
                    padata-value: 303da003020117a23604340f475b2eeff0ed60adf9bbdd336238c371a297bd8e945eaf60…
                        etype: eTYPE-ARCFOUR-HMAC-MD5 (23)
                        cipher: 0f475b2eeff0ed60adf9bbdd336238c371a297bd8e945eaf60abaa0a5c32f914126fddec…
            PA-DATA pA-PAC-REQUEST
                padata-type: pA-PAC-REQUEST (128)
                    padata-value: 3005a0030101ff
                        include-pac: True
        req-body
            Padding: 0
            kdc-options: 40810010
                0... .... = reserved: False
                .1.. .... = forwardable: True
                ..0. .... = forwarded: False
                ...0 .... = proxiable: False
                .... 0... = proxy: False
                .... .0.. = allow-postdate: False
                .... ..0. = postdated: False
                .... ...0 = unused7: False
                1... .... = renewable: True
                .0.. .... = unused9: False
                ..0. .... = unused10: False
                ...0 .... = opt-hardware-auth: False
                .... 0... = unused12: False
                .... .0.. = unused13: False
                .... ..0. = constrained-delegation: False
                .... ...1 = canonicalize: True
                0... .... = request-anonymous: False
                .0.. .... = unused17: False
                ..0. .... = unused18: False
                ...0 .... = unused19: False
                .... 0... = unused20: False
                .... .0.. = unused21: False
                .... ..0. = unused22: False
                .... ...0 = unused23: False
                0... .... = unused24: False
                .0.. .... = unused25: False
                ..0. .... = disable-transited-check: False
                ...1 .... = renewable-ok: True
                .... 0... = enc-tkt-in-skey: False
                .... .0.. = unused29: False
                .... ..0. = renew: False
                .... ...0 = validate: False
            cname
                name-type: kRB5-NT-PRINCIPAL (1)
                cname-string: 1 item
                    CNameString: Administrator
            realm: ice.com
            sname
                name-type: kRB5-NT-SRV-INST (2)
                sname-string: 2 items
                    SNameString: krbtgt
                    SNameString: ice.com
            till: 2037-09-13 02:48:05 (UTC)
            rtime: 2037-09-13 02:48:05 (UTC)
            nonce: 55659252
            etype: 6 items
                ENCTYPE: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
                ENCTYPE: eTYPE-AES128-CTS-HMAC-SHA1-96 (17)
                ENCTYPE: eTYPE-ARCFOUR-HMAC-MD5 (23)
                ENCTYPE: eTYPE-ARCFOUR-HMAC-MD5-56 (24)
                ENCTYPE: eTYPE-ARCFOUR-HMAC-OLD-EXP (-135)
                ENCTYPE: eTYPE-DES-CBC-MD5 (3)
            addresses: 1 item ACE<20>
                HostAddress ACE<20>
                    addr-type: nETBIOS (20)
                    NetBIOS Name: ACE<20> (Server service)

AS-REQ数据包分析

pvno

pvno: 5
pvno代表Kerberos版本，这里代表kerbev5

msg-type

msg-type: krb-as-req (10)
代表此阶段是krb-as-req

patata

patata

pA-ENC-TIMESTAMP 预认证数据，用户密码hash作为密钥加密时间戳，加密后发送至AS,AS使用用户密码hash进行解密，若解密成功且时间戳在范围内则认证成功

pA-PAC-REQUEST 启用PAC支持的扩展，KDC通过对应的include判断票据是否携带PAC,include-pac: True则是携带

req-body部分

kdc-options

kdc-options 标志位字段

cname

cname 主要包含登录用户及所在域，可以看见有CNameString: Administrator与realm: ice.com
            cname
                name-type: kRB5-NT-PRINCIPAL (1)
                cname-string: 1 item
                    CNameString: Administrator
            realm: ice.com
 
 使用krbtgt账户登录
             sname
                name-type: kRB5-NT-SRV-INST (2)
                sname-string: 2 items
                    SNameString: krbtgt
                    SNameString: ice.com
                    
  使用账户名@域名登录
              cname
                name-type: kRB5-NT-ENTERPRISE-PRINCIPAL (10)
                cname-string: 1 item
                    CNameString: [e-mail]
            realm: ice.com

sname

            sname
                name-type: kRB5-NT-SRV-INST (2)
                sname-string: 2 items
                    SNameString: krbtgt
                    SNameString: ice.com
            till: 2037-09-13 02:48:05 (UTC)
            rtime: 2037-09-13 02:48:05 (UTC)
            nonce: 55659252
            
被请求的服务信息，所在域名，till为到期时间，rtime绝对到期时间（若请求为可更新票据），nonce为生成的随机数

etype

            etype: 6 items
                ENCTYPE: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
                ENCTYPE: eTYPE-AES128-CTS-HMAC-SHA1-96 (17)
                ENCTYPE: eTYPE-ARCFOUR-HMAC-MD5 (23)
                ENCTYPE: eTYPE-ARCFOUR-HMAC-MD5-56 (24)
                ENCTYPE: eTYPE-ARCFOUR-HMAC-OLD-EXP (-135)
                ENCTYPE: eTYPE-DES-CBC-MD5 (3)
                
加密类型，通过该字段的加密类型来选择用户hash进行解密

address

            addresses: 1 item ACE<20>
                HostAddress ACE<20>
                    addr-type: nETBIOS (20)
                    NetBIOS Name: ACE<20> (Server service)

客户端相关信息

AS-REP数据包

#数据包
Kerberos
    Record Mark: 1439 bytes
        0... .... .... .... .... .... .... .... = Reserved: Not set
        .000 0000 0000 0000 0000 0101 1001 1111 = Record Length: 1439
    as-rep
        pvno: 5
        msg-type: krb-as-rep (11)
        crealm: ICE.COM
        cname
            name-type: kRB5-NT-PRINCIPAL (1)
            cname-string: 1 item
                CNameString: Administrator
        ticket
            tkt-vno: 5
            realm: ICE.COM
            sname
                name-type: kRB5-NT-SRV-INST (2)
                sname-string: 2 items
                    SNameString: krbtgt
                    SNameString: ICE.COM
            enc-part
                etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
                kvno: 2
                cipher: e27c799a41636c2cb2142186f5378eb58980d6ee3e7d2fc418a07ba1fdc2244dd5e1dd1a…
        enc-part
            etype: eTYPE-ARCFOUR-HMAC-MD5 (23)
            kvno: 1
            cipher: b523e9f8d46e97620799248ff3e562d8fd84fb95da93c413cd011871fd98a5a78edcaa21…

AS-REP数据包分析

客户端发送AS-REQ请求凭证是用户hash加密的时间戳，凭证在padata内，当AS收到后，AS通过用户hash进行解密，获得时间戳，若解密成功则代表预认证成功，接着将发送响应包，主要包含krbtgt用户hash加密后的TGT票据及用户hash加密的 login session key

ticket

        ticket
            tkt-vno: 5
            realm: ICE.COM
            sname
                name-type: kRB5-NT-SRV-INST (2)
                sname-string: 2 items
                    SNameString: krbtgt
                    SNameString: ICE.COM
            enc-part
                etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
                kvno: 2
                cipher: e27c799a41636c2cb2142186f5378eb58980d6ee3e7d2fc418a07ba1fdc2244dd5e1dd1a…
                
                
krbtgt用户hash进行加密的TGT票据，因为域内ticket都由krbtgt hash进行加密,假设可获得krbtgt的hash、sid则可进行伪造黄金票据；tkt-vno为票据的版本号
realm为颁发票据的域名称
sname为票据对应的服务端，认与先前的AS-REQ内一致
enc-part为KDCkrbtgt密钥加密的票据 

enc-pat

        enc-part
            etype: eTYPE-ARCFOUR-HMAC-MD5 (23)
            kvno: 1
            cipher: b523e9f8d46e97620799248ff3e562d8fd84fb95da93c413cd011871fd98a5a78edcaa21…
            
这里加密使用的是用户的hash与ticket中的enc-part不同，包含login session key，用户使用用户hash解密后属于下一步客户端与KDC认证的密钥

其中AS-REQ数据包中最重要的有两个字段：

1、pA-ENC-TIMESTAMP，这是预认证数据，用户密码hash作为密钥加密时间戳，加密后发送至AS,AS使用用户密码hash进行解密，若解密成功且时间戳在范围内则认证成功

2、pA-PAC-REQUEST，启用PAC支持的扩展，KDC通过对应的include判断票据是否携带PAC,include-pac: True则是携带

其中AS-REP主要是为了获取TGT及login session key并缓存到本地，客户端将使用自身hash解密login session key获得原始的login session key，原始login session key是下一步客户端域KDC认证的密钥

AS-REQ&AS-REP安全问题

• 在第一部分中由于认证的时候使用client hash，所以不需要有明文密码就可以认证即pass the hash&pass the key

• 在第一部分中由于用户名正确和用户名错误返回信息的error-code字段不同，所以可以枚举用户名

• 在第一部分中的TGT的encpart是krbtgt hash加密的，如果有krbtgt hash 就可以签发任意用户，即黄金票据

• 在第一部分中，如果域控那边设置了"Do not require Kerberos preauthentication"，不要求Kerberos预身份验证(默认不开启)可以对收到的AS_REP重新组合拼接，就可以用hashcat解密获得明文密码，即AS-REPRoasting

TGS_REQ&TGS_REP

这一部分主要是为了获取请求服务的票据

TGS-REQ数据包

#数据包
Kerberos
    Record Mark: 1395 bytes
        0... .... .... .... .... .... .... .... = Reserved: Not set
        .000 0000 0000 0000 0000 0101 0111 0011 = Record Length: 1395
    tgs-req
        pvno: 5
        msg-type: krb-tgs-req (12)
        padata: 2 items
            PA-DATA pA-TGS-REQ
                padata-type: pA-TGS-REQ (1)
                    padata-value: 6e8204c6308204c2a003020105a10302010ea20703050000000000a38204116182040d30…
                        ap-req
                            pvno: 5
                            msg-type: krb-ap-req (14)
                            Padding: 0
                            ap-options: 00000000
                                0... .... = reserved: False
                                .0.. .... = use-session-key: False
                                ..0. .... = mutual-required: False
                            ticket
                                tkt-vno: 5
                                realm: ICE.COM
                                sname
                                    name-type: kRB5-NT-SRV-INST (2)
                                    sname-string: 2 items
                                        SNameString: krbtgt
                                        SNameString: ICE.COM
                                enc-part
                                    etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
                                    kvno: 2
                                    cipher: e27c799a41636c2cb2142186f5378eb58980d6ee3e7d2fc418a07ba1fdc2244dd5e1dd1a…
                            authenticator
                                etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
                                cipher: 8f80fb7d52ea5f8400967eccc47aaaa08312e89811fe9856954b5a06fbe1781001db17d5…
            PA-DATA pA-PAC-OPTIONS
                padata-type: pA-PAC-OPTIONS (167)
                    padata-value: 3009a00703050040000000
                        Padding: 0
                        flags: 40000000
                            0... .... = claims: False
                            .1.. .... = branch-aware: True
                            ..0. .... = forward-to-full-dc: False
                            ...0 .... = resource-based-constrained-delegation: False
        req-body
            Padding: 0
            kdc-options: 40810000
                0... .... = reserved: False
                .1.. .... = forwardable: True
                ..0. .... = forwarded: False
                ...0 .... = proxiable: False
                .... 0... = proxy: False
                .... .0.. = allow-postdate: False
                .... ..0. = postdated: False
                .... ...0 = unused7: False
                1... .... = renewable: True
                .0.. .... = unused9: False
                ..0. .... = unused10: False
                ...0 .... = opt-hardware-auth: False
                .... 0... = unused12: False
                .... .0.. = unused13: False
                .... ..0. = constrained-delegation: False
                .... ...1 = canonicalize: True
                0... .... = request-anonymous: False
                .0.. .... = unused17: False
                ..0. .... = unused18: False
                ...0 .... = unused19: False
                .... 0... = unused20: False
                .... .0.. = unused21: False
                .... ..0. = unused22: False
                .... ...0 = unused23: False
                0... .... = unused24: False
                .0.. .... = unused25: False
                ..0. .... = disable-transited-check: False
                ...0 .... = renewable-ok: False
                .... 0... = enc-tkt-in-skey: False
                .... .0.. = unused29: False
                .... ..0. = renew: False
                .... ...0 = validate: False
            realm: ICE.COM
            sname
                name-type: kRB5-NT-SRV-HST (3)
                sname-string: 2 items
                    SNameString: host
                    SNameString: ace.ice.com
            till: 2037-09-13 02:48:05 (UTC)
            nonce: 55659255
            etype: 5 items
                ENCTYPE: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
                ENCTYPE: eTYPE-AES128-CTS-HMAC-SHA1-96 (17)
                ENCTYPE: eTYPE-ARCFOUR-HMAC-MD5 (23)
                ENCTYPE: eTYPE-ARCFOUR-HMAC-MD5-56 (24)
                ENCTYPE: eTYPE-ARCFOUR-HMAC-OLD-EXP (-135)

此处用户已通过AS-REP获得TGT票据、login session key后，下一步需获取ST

TGS-REQ数据包分析

patata

主要包含TGT与authenticator
其中ticket部分中enc-part同AS-REQ后得到的TGT票据一致，为先前得到的TGT，用此TGT票据请求TGS获得ST(KDC校验TGT票据，如果票据正确，就返回TGS票据)：
                            ticket
                                tkt-vno: 5
                                realm: ICE.COM
                                sname
                                    name-type: kRB5-NT-SRV-INST (2)
                                    sname-string: 2 items
                                        SNameString: krbtgt
                                        SNameString: ICE.COM
                                enc-part
                                    etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
                                    kvno: 2
                                    cipher: e27c799a41636c2cb2142186f5378eb58980d6ee3e7d2fc418a07ba1fdc2244dd5e1dd1a…
                                    
ticket部分中authenticator,通过先前AS-REQ的login session key作为密钥加密的时间戳,属于下一步认证使用的会话密钥：
                            authenticator
                                etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
                                cipher: 8f80fb7d52ea5f8400967eccc47aaaa08312e89811fe9856954b5a06fbe1781001db17d5…

sname

            sname
                name-type: kRB5-NT-SRV-HST (3)
                sname-string: 2 items
                    SNameString: host
                    SNameString: ace.ice.com
                    
请求的服务名称，这里是要登录的主机

msg-type

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

PA_FOR_USER

 (没有该扩展则没有该字段)

类型是S4U2SELF
值是一个唯一的标识符，该标识符指示用户的身份 该唯一标识符由用户名和域名组成
S4U2proxy 必须扩展PA_FOR_USER结构，指定服务代表某个用户(图片里面是administrator)去请求针对服务自身的kerberos服务票据

AddtionTicket

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

TGS-REP数据包

#数据包
Frame 24: 1496 bytes on wire (11968 bits), 1496 bytes captured (11968 bits) on interface \Device\NPF_{879152E5-EF23-42E8-8120-79F84CBA70CC}, id 0
Ethernet II, Src: VMware_94:3d:24 (00:0c:29:94:3d:24), Dst: VMware_11:4f:dc (00:0c:29:11:4f:dc)
Internet Protocol Version 4, Src: 192.168.5.5, Dst: 192.168.5.10
Transmission Control Protocol, Src Port: 88, Dst Port: 54152, Seq: 1, Ack: 1400, Len: 1442
Kerberos
    Record Mark: 1438 bytes
        0... .... .... .... .... .... .... .... = Reserved: Not set
        .000 0000 0000 0000 0000 0101 1001 1110 = Record Length: 1438
    tgs-rep
        pvno: 5
        msg-type: krb-tgs-rep (13)
        crealm: ICE.COM
        cname
            name-type: kRB5-NT-PRINCIPAL (1)
            cname-string: 1 item
                CNameString: Administrator
        ticket
            tkt-vno: 5
            realm: ICE.COM
            sname
                name-type: kRB5-NT-SRV-HST (3)
                sname-string: 2 items
                    SNameString: host
                    SNameString: ace.ice.com
            enc-part
                etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
                kvno: 1
                cipher: 34f29a84445aeb2ad92569d593dd53ca62a430c87e690ad20778f9ddf6a7669bd37a9c49…
        enc-part
            etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
            cipher: f5e86cff77532c3bb7548de53e544e4fcf43a3a579502281e03e7098a439017308343d4c…

当TGS收到请求后将检查是否拥有用户请求的服务，若服务存在，通过krbtgt hash解密TGT获得login session key,再用login session key解密authenticator，将校验对方身份、时间戳是否过期，校验通过后将发送ST票据

TGS-REP数据包分析

ticket

这里返回的其实是ST，enc-part使用服务对应的密钥进行加密,用户不可读取里面的内容
        ticket
            tkt-vno: 5
            realm: ICE.COM
            sname
                name-type: kRB5-NT-SRV-HST (3)
                sname-string: 2 items
                    SNameString: host
                    SNameString: ace.ice.com
            enc-part
                etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
                kvno: 1
                cipher: 34f29a84445aeb2ad92569d593dd53ca62a430c87e690ad20778f9ddf6a7669bd37a9c49…

enc-part

经过login session key（AS-REP）加密的service session key，包含服务身份信息等，用于请求服务时的会话密钥
        enc-part
            etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
            cipher: f5e86cff77532c3bb7548de53e544e4fcf43a3a579502281e03e7098a439017308343d4c…
当前阶段流程完成认证将发送给客户端两项内容，TGS生产的ST，以及AS-REP返回的login session key加密的service session key    任意用户只要hash正确都可以请求域内任何一个服务票据,service session key 作为下一阶段认证的密钥

msg-type

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

S4U2self

允许服务代表任意用户请求访问自身服务的ST服务票据，服务是不需要用户的凭据的

S4U2self 使得服务可以代表用户获得针对服务自身的kerberos服务票据。这使得服务可以获得用户的授权( 可转发 的用户TGS票据)，然后将其用于后期的认证(主要是后期的s4u2proxy)，这是为了在用户以不使用 Kerberos 的方式对服务进行身份验证的情况下使用

步骤1中, 服务使用S4U2self扩展名代表用户(administrator)获得针对服务本身的服务票证 
该服务将填写PA_FOR_USER数据结构,类型为S4U2SELF，并将KRB_TGS_REQ消息发送到TGS

TGS在步骤2中通过KRB_TGS_REP消息返回用户的服务票证(需要支持PA_FOR_USER扩展)

如果服务请求了可转发选项，并且TGS的本地策略允许，则TGS检验通过后必须将票证标志字段设置为可转发
需要满足
1.TGT是可以转发的 
2.服务配置了约束委派 
3.服务请求了可转发选项

如果用户的UserAccountControl字段中设置了USER_NOT_DELEGATED位,那么返回的TGS是永远也没法转发的

S4U2proxy

允许服务在已取得ST服务票据下代表任意用户获取另一个服务的服务票据

s4u2proxy 使得服务1可以使用来自用户的授权( 在S4U2SELF阶段获得)，然后用该TGS(放在AddtionTicket里面)向KDC请求访问服务2的TGS，并且代表用户访问服务2，而且只能访问服务2

用做约束委派的，账户的msDS-AllowedToDelegateTo属性，添加允许委派的服务

步骤1中，服务1试图代表用户获取服务2的服务票证。服务1发送KRB_TGS_REQ消息，并将用户的服务1服务票证作为 请求中的AddtionTicket

需要满足条件 
1.拥有来自用户的授权( 在S4U2SELF阶段获得的TGS票据)，放在AddtionTicket里面
2.在请求的kdc-options中设置了CNAME-IN-ADDL-TKT标志
3.服务请求了可转发选项
4.服务1 有到服务2的约束委派，将服务2的SPN放在sname里面

满足这些之后，在步骤2中TGS会制作KRB_TGS_REP消息以返回服务票证（可转发标志将在服务票证中设置）

注意

前面在S4U2SELF里面提到，在满足一定的条件之后，S4U2SELF返回的票据是可以转发的，这个票据作为S4U2PROXY的AddtionTicket，有些文章里面会说，S4U2PROXY要求AddtionTicket里面的票据一定要是可转发的，否则S4U2PROXY生成的票据是不可以转发的。这个说法在引入资源约束委派的情况下，是不成立的
分两种情况
1.如果AddtionTicket里面的票据是可转发的，只要KDC Options里面置forwarable位，那么返回的票据必须置为可转发的
2.如果AddtionTicket中的服务票据未设置为可转发的，则KDC必须返回状态为STATUS_NO_MATCH的KRB-ERR-BADOPTION选项
但是配置了服务1到服务2 的基于资源的约束委派，且PA-PAC-OPTION设置了Resource-Based Constrained Delegation标志位(这一例外的前提是S4U2SELF阶段模拟的用户没被设置为对委派敏感，对委派敏感的判断在S4U2SELF阶段,而不是S4U2PROXY阶段),这种情况是可以转发的

TGS-REQ&TGS-REP安全问题

• 在第二部分中的TGS是server hash加密的，如果我们拥有服务权限即可伪造票据访问此服务，即白银票据，如果对方配置了KDC签名的PAC，白银票据将无法使用

• 在第二部分中的TGS是server hash加密的，可以爆破服务的hash，即kerberosting

• 在第二部分和第三部分都是使用票据认证，就造成了pass the ticket

AP-REQ&AP-REP

这一部分主要是判断用户访问权限

这一部分是本地服务，wireshark无法抓包

AP-REQ

客户端收到服务端返回的ST与enc-part,使用缓存的login session key解密enc-part获得service session key，本地缓存server session key与ST，请求服务时将ST和service session key加密后的时间戳信息发送给server

AS-REP

server收到相关数据，使用service key解密TGS的ticket的enc-part，获得service session key，使用service session key解密authentication后对authenticator进行验证，通过后返回新的时间戳，客户端通过service session key解密返回的时间戳，进行验证，通过则证明客户端可信赖服务器，并发送服务请求，服务器对客户端提供相应服务

PAC

如果没有PAC,那么一般的kerberos流程里只要用户的hash正确，那么就可以拿到TGT，有了TGT，就可以拿到TGS，有了TGS，就可以访问服务，任何一个用户都可以访问任何服务，只验证了身份，而没有验证权限
PAC包含了用户的sid和用户所在组

PAC整体的结构上是一个AuthorizationData的结构

AuthorizationData       ::= SEQUENCE OF SEQUENCE {
              ad-type         [0] Int32,
              ad-data         [1] OCTET STRING
 }
#AuthorizationData结构的ad-type
AD-IF-RELEVANT                     1
AD-INTENDED-FOR-SERVER             2
AD-INTENDED-FOR-APPLICATION-CLASS  3
AD-KDC-ISSUED                      4
AD-AND-OR                          5
AD-MANDATORY-TICKET-EXTENSIONS     6
AD-IN-TICKET-EXTENSIONS            7
AD-MANDATORY-FOR-KDC               8
Reserved values                 9-63
OSF-DCE                           64
SESAME                            65
AD-OSF-DCE-PKI-CERTID             66 (hemsath @us.ibm.com)
AD-WIN2K-PAC                     128 (jbrezak @exchange.microsoft.com)
AD-ETYPE-NEGOTIATION             129  (lzhu @windows.microsoft.com)

图中PAC最外层的ad-type为AD-IF-RELEVANT，AuthorizationData的ad-type 为AD-WIN2K-PAC

ad-data为一段连续的空间，包含一个头部PACTYPE以及若干个PAC_INFO_BUFFER

头部PACTYPE包括cBuffers,版本以及缓冲区

PAC_INFO_BUFFER为key-value型的，如下

类型	意义
0x00000001	登录信息。PAC结构必须包含一个这种类型的缓冲区。其他登录信息缓冲区必须被忽略。
0x00000002	凭证信息。PAC结构不应包含多个此类缓冲区。第二或后续凭证信息缓冲区在接收时必须被忽略。
0x00000006	服务器校验和。PAC结构必须包含一个这种类型的缓冲区。其他登录服务器校验和缓冲区必须被忽略。
0x00000007	KDC校验和。PAC结构必须包含一个这种类型的缓冲区。附加的KDC校验和缓冲区必须被忽略。
0x0000000A	客户名称和票证信息。PAC结构必须包含一个这种类型的缓冲区。附加的客户和票据信息缓冲区必须被忽略
0x0000000B	受约束的委派信息。PAC结构必须包含一个S4U2proxy请求的此类缓冲区，否则不包含。附加的受约束的委托信息缓冲区必须被忽略。
0x0000000C	用户主体名称（UPN）和域名系统（DNS）信息。PAC结构不应包含多个这种类型的缓冲区。接收时必须忽略第二个或后续的UPN和DNS信息缓冲区。
0x0000000D	客户索取信息。PAC结构不应包含多个这种类型的缓冲区。附加的客户要求信息缓冲区必须被忽略。
0x0000000E	设备信息。PAC结构不应包含多个这种类型的缓冲区。附加的设备信息缓冲区必须被忽略。
0x0000000F	设备声明信息。PAC结构不应包含多个这种类型的缓冲区。附加的设备声明信息缓冲区必须被忽略。

安全问题

• Microsoft Windows Kerberos KDC无法正确检查Kerberos票证请求随附的特权属性证书（PAC）中的有效签名，导致用户可以自己构造一张PAC，即MS14068

委派

域委派是指将域内用户的权限委派给服务账户，使得相关服务账户能够以域用户的身份权限获得相关域内服务资源的访问权限

非约束委派

在非约束性委派中，服务账号可以获取域用户的 TGT，并使用该 TGT 模拟域用户访问任意服务

这需要域管理员特权(SeEnableDelegation特权，该特权很敏感，通常仅授予域管理员)才能为服务配置域帐户，并且将帐户限制为单个域

配置了非约束委派的用户的userAccountControl 属性有个FLAG位 TrustedForDelegation

流程

简单了解即可

（1）域用户的机器向密钥分发中心（KDC）发送 KRB_AS_REQ 消息，并请求可转发的 TGT 1。
（2）KDC 在 KRB_AS_REP 消息中返回一个可转发的 TGT 1，该 TGT 1 用于后续访问服务1（Service 1）使用。
（3）用户根据步骤（2）中的可转发 TGT 1 请求转发 TGT 2，该过程通过 KRB_TGS_REQ 消息完成。
（4）KDC 在 KRB_TGS_REP 消息中为用户返回一个转发的 TGT 2，该 TGT 2 用于后续访问服务2（Service 2）使用。
（5）用户使用步骤（2）中返回的 TGT 1 向 KDC 请求 Service 1 的服务票据，该过程通过 KRB_TGS_REQ 消息完成。
（6）TGS 票据授予服务在 KRB_TGS_REP 消息中为用户返回 Service 1 的服务票据（ST 1）。
（7）用户通过发送 KRB_AP_REQ 消息向 Service 1 发出访问请求，同时提供 ST 1、可转发的 TGT 1、TGT 2 以及 TGT 2 的会话密钥（Session Key）。
（8）为了满足用户的请求，Service 1 需要代表用户执行一些操作。Service 1 使用转发的 TGT 2 并将其通过 KRB_TGS_REQ 消息发送到 KDC，以用户的名义请求 Service 2 的 ST 2。
（9）KDC 在 KRB_TGS_REP 消息中将 Service 2 的 ST 2 连同 Service 1 可以使用的 Session Key 一起返回给 Service 1。需要注意的是，这里返回的 ST 2 将客户端标识为用户，而不是 Service 1。
（10）Service 1 以用户的身份通过 KRB_AP_REQ 消息向 Service 2 发出访问请求。
（11）Service 2 响应 Service 1 的访问请求。
（12）在得到 Service 2 的响应后，Service 1 现在可以响应用户在步骤（7）中发出的访问请求了。
（13）此处描述的 TGT 转发委派机制不限制 Service 1 使用转发的 TGT。 Service 1 可以以用户的名义向 KDC 索要任何其他服务的票据。
（14）KDC 将返回请求的服务票据。
（15）然后，Service 1 可以继续使用用户的身份访问其他服务。
（16）Service N 将响应 Service 1，就好像它是用户的进程一样。

查询非约束委派账户

# 查询域中配置非约束委派的机器账户
AdFind.exe -b "dc=ice,dc=com" -f "(&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288))" -dn
# 查询域中配置非约束委派的服务账户
AdFind.exe -b "dc=ice,dc=com" -f "(&(samAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=524288))" -dn

约束委派

由于非约束委派的不安全性引入了约束委派，大致就是在非约束委派访问的服务做了限制

这需要域管理员特权(SeEnableDelegation特权，该特权很敏感，通常仅授予域管理员)才能为服务配置域帐户，并且将帐户限制为单个域

S4U2self 扩展允许服务代表用户获取针对自己的服务票据，S4U2proxy 允许服务代表用户获取另一个服务的服务票据。约束委派就是限制了 S4U2proxy 扩展的请求范围，使得配置了委派属性的服务只能模拟用户身份访问特定的其他服务

配置了约束性委派的账户的 userAccountControl 属性会设置 TRUSTED_TO_AUTH_FOR_DELEGATION 标志位，并且账户的 msDS-AllowedToDelegateTo 属性会被设置为对哪些服务进行委派

配置从服务1到服务2的约束委派

流程简述

约束委派流程
1.服务1 使用自己的hash向KDC申请一个TGT票据，注意在KDC Option里面选择FORWARDABLE标志位，这样的话请求的TGT票据就是可转发的TGT票据
2.服务1 代表用户申请一个获得针对服务1自身的kerberos服务票据(这一步就是S4U2SELF)，这一步生成的TGS票据是可转发的TGS票据
3.服务1可以使用来自用户的授权( 在S4U2SELF阶段获得的可转发的TGS)，然后用该TGS(放在AddtionTicket里面)向KDC请求访问服务2的TGS

查询约束委派账户

# 查询域中配置约束委派的机器账户
AdFind.exe -b "dc=ice,dc=com" -f "(&(samAccountType=805306369)(msds-allowedtodelegateto=*))" msds-allowedtodelegateto
# 查询域中配置约束委派的服务账户
AdFind.exe -b "dc=ice,dc=com" -f "(&(samAccountType=805306368)(msds-allowedtodelegateto=*))" msds-allowedtodelegateto

msDS-AllowedToDelegateTo 属性是对哪些服务进行委派

基于资源的约束委派

在 Windows Server 2012 中新引入的功能，它是将设置委派的权限交换给了服务资源自身

在 Service 2 上将 msDS-AllowedToActOnBehalfOfOtherIdentity 属性值设为 Service 1 的 SID，以允许 Service 1 对 Service 2 上的服务进行委派

设置是在被访问的服务一方

流程简述

1.服务1 使用自己的hash向KDC申请一个TGT票据
2.服务1 代表用户申请一个获得针对服务1自身的kerberos服务票据(这一步就是S4U2SELF),这一步返回的TGS是不能转发的，与约束委派不一样
3.服务1可以使用来自用户的授权( 在S4U2SELF阶段获得的不可转发的TGS)，然后用该TGS(放在AddtionTicket里面)向KDC请求访问服务2的可转发的TGS

安全问题

• 非约束委派攻击

• 约束委派攻击

• 基于资源的约束委派攻击

这个类似于黄金票据，可以用于维权

Kerberos中继

在之前认为kerberos无法中继是因为kerberos加起来同学前双方身份的认定工作，通过在Authentication Server Request (AS_REQ)中添加服务主体名称(SPN) ，导致最终获取的ST无法用于与其他SS(Service Server)通信，从而阻止中继到与服务主体名称不同的服务

Kerberos中继原理

攻击者可以控制SPN，就可以顺利中继到任意服务器，需要以下两个条件

1、部分协议可以强制受害者向攻击者进行强制身份认证，并在Kerberos身份认证时允许指定不同的SPN，包括以下协议

● IPSec and AuthIP

● MSRPC

● DCOM

● HTTP

● LLMNR

● MDNS

2、身份验证中继到的服务使用的协议，此协议要求不设置强制签名，包括以下协议：

● LDAP/LDAPS

● HTTP

● SMB

攻击流程：

参考

https://daiker.gitbook.io/windows-protocol/kerberos

深入浅出域委派攻击 | WHOAMI's Blog (whoamianony.top)

奇安信攻防社区-红队域渗透技术：委派攻击汇总（全） (butian.net)

https://www.cnblogs.com/Yang34/p/14248737.html