德州建设公司网站,一个网站的seo优化有哪些,徐州seo网站推广,qa wordpress目录
一、Kerberos协议
二、下面我们来具体分析Kerberos认证流程的每个步骤#xff1a;
1、KRB_AS-REQ请求包分析
PA-ENC-TIMESTAMP
PA_PAC_REQUEST
2、 KRB_AS_REP回复包分析#xff1a;
TGT认购权证
Logon Session Key
ticket
3、然后继续来讲相关的TGS的认证过程…目录
一、Kerberos协议
二、下面我们来具体分析Kerberos认证流程的每个步骤
1、KRB_AS-REQ请求包分析
PA-ENC-TIMESTAMP
PA_PAC_REQUEST
2、 KRB_AS_REP回复包分析
TGT认购权证
Logon Session Key
ticket
3、然后继续来讲相关的TGS的认证过程
KRB_TGS_REQ(请求)
KRB_TGS_REP(应答)
4、cilent访问服务端
KRB_AP_REQ(请求)
KRB_AP_REP(应答)
三、黄金票据的原理和条件
1原理
2条件
3.黄金票据的局限性
4.绕过黄金票据局限性
5.黄金票据的特点
6.黄金票据防御
四、实践
1权限提升privilege::debug
2获得krbtgt账户的SID 、krbtgt:hash (3)生成票据并利用 (4)测试 一、Kerberos协议
在学习黄金白银票据前首先的了解一下什么是Kerberos认证 Kerberos是一种由MIT麻省理工大学提出的一种网络身份验证协议。它旨在通过使用密钥加密技术为客户端/服务器应用程序提供强身份验证。
在 Kerberos 认证中最主要的问题是如何证明「你是你」的问题如当一个 Client 去访问 Server 服务器上的某服务时Server 如何判断 Client 是否有权限来访问自己主机上的服务同时保证在这个过程中的通讯内容即使被拦截或篡改也不影响通讯的安全性这正是 Kerberos 解决的问题。在域渗透过程中 Kerberos 协议的攻防也是很重要的存在。
Kerberos 主要是用在域环境下的身份认证协议。 内网渗透-Windows域环境的初识与搭建_域的登录模式和过程-CSDN博客 在Kerberos协议中主要是有三个角色的存在 访问服务的客户端Kerberos客户端是代表需要访问资源的用户进行操作的应用程序例如打开文件、查询数据库或打印文档。每个Kerberos客户端在访问资源之前都会请求身份验证。 提供服务的服务端域内提供服务的服务端服务端都有一个独一的SPN。 提供认证服务的KDC(Key Distribution Center密钥分发中心)KDC密钥发行中心是一种网络服务它向活动目录域内的用户和计算机提供会话票据和临时会话密钥其服务帐户为krbtgt。KDC作为活动目录域服务ADDS的一部分运行在每个域控制器上。 这里说一下krbtgt帐户该用户是在创建活动目录时系统自动创建的一个账号其作用是KDC密钥发行中心的服务账号其密码是系统随机生成的无法正常登陆主机。在后面的域学习中会经常和krbtgt帐户打交道关于该帐户的其他信息会在后面的文章中详细讲解。
其中KDC服务默认会安装在一个域的域控中而Client和Server为域内的用户或者是服务如HTTP服务SQL服务。在Kerberos中Client是否有权限访问Server端的服务由KDC发放的票据来决定。 kerberos的简化认证认证过程如下图 AS_REQ: Client向KDC发起AS_REQ,请求凭据是Client hash加密的时间戳 AS_REP: KDC使用Client hash进行解密如果结果正确就返回用krbtgt hash加密的TGT票据TGT里面包含PAC,PAC包含Client的sidClient所在的组。 TGS_REQ: Client凭借TGT票据向KDC发起针对特定服务的TGS_REQ请求 TGS_REP: KDC使用krbtgt hash进行解密如果结果正确就返回用服务hash 加密的TGS票据(这一步不管用户有没有访问服务的权限只要TGT正确就返回TGS票据) AP_REQ: Client拿着TGS票据去请求服务 AP_REP: 服务使用自己的hash解密TGS票据。如果解密正确就拿着PAC去KDC那边问Client有没有访问权限域控解密PAC。获取Client的sid以及所在的组再根据该服务的ACL判断Client是否有访问服务的权限。
通俗版Kerberos是一种基于票据Ticket的认证方式。客户端想要访问服务端的某个服务首先需要购买服务端认可的 ST服务票据(Service Ticket)。也就是说客户端在访问服务之前需要先买好票等待服务验票之后才能访问。但是这张票并不能直接购买需要一张 TGT认购权证Ticket Granting Ticket)。也就是说客户端在买票之前必须先获得一张TGT认购权证。TGT认购权证 和 ST服务票据 均是由KDC(密钥分发中心)发放因为KDC是运行在域控制器上所以说TGT认购权证和ST服务票据均是由域控发放。
Kerberos协议其中有两个基础认证模块AS_REQ AS_REP 和 TGS_REQ TGS_REP 以及微软扩展的两个认证模块 S4U 和 PAC 。S4U是微软为了实现委派而扩展的模块分为 S4U2Self 和 S4U2Proxy 。在Kerberos最初设计的流程里只说明了如何证明客户端的真实身份但是并没有说明客户端是否有权限访问该服务因为在域中不同权限的用户能够访问的资源是不同的。因此微软为了解决权限这个问题引入了 PAC (Privilege Attribute Certificate特权属性证书) 的概念。
二、下面我们来具体分析Kerberos认证流程的每个步骤
AS-REQ AS-REP
如图所示是一个简易的AS-REQAS-REP请求过程图便于我们直观的了解AS-REQAS-REP请求过程。 1、KRB_AS-REQ请求包分析
Client-ASClient 先向 KDC 的 AS 发送 pA-ENC-TIMESTAMP内容为Client hash加密的时间戳
AS-REQ当域内某个用户想要访问域内某个服务时于是输入用户名和密码本机就会向KDC的AS认证服务发送一个AS-REQ认证请求。该请求包中包含如下信息
· 请求的用户名(cname)。
· 域名(realm)。
· Authenticator一个抽象的概念代表一个验证。这里是用户密钥加密的时间戳。
· 请求的服务名(sname)AS-REQ这个阶段请求的服务都是krbtgt。
· 加密类型(etype)。
· 以及一些其他信息如版本号消息类型票据有效时间是否包含PAC协商选项等。
用户向KDC发起AS_REQ,请求凭据是用户 hash加密的时间戳。请求凭据放在PA_DATA里面
在AS_REQ阶段主要用到的有两个 PA-ENC-TIMESTAMP PA-DATA PA-ENC-TIMESTAMP这个是预认证就是用用户Hash加密时间戳作为value发送给KDC的AS服务。然后KDC从活动目录中查询出用户的hash使用用户Hash进行解密获得时间戳如果能解密且时间戳在一定的范围内则证明认证通过。由于是使用用户密码Hash加密的时间戳所以也就造成了哈希传递攻击 PA_PAC_REQUEST 这个是启用PAC支持的扩展。PAC并不在原生的kerberos里面是微软引进的扩展。详细的内容之后将有一篇文章详细介绍PAC。PAC包含在AS_REQ的响应body(AS_REP)。这里的value对应的是includetrue或者includefalse(KDC根据include的值来判断返回的票据中是否携带PAC)。
2、 KRB_AS_REP回复包分析
AS-ClientAS根据用户名在AD中寻找是否在AD数据库中然后根据Client的用户名提取到对应的Hash接着pA-ENC-TIMESTAMP用对应Client用户名的Hash进行解密如果结果正确则会返回如下
1、返回当前KDC中krbtgt hash加密的TGT票据TGT包含PACPAC包含Client的sidClient所在的组在通信数据包中显示的就是ticket字段
2、Authentication Service会生成一个随机数Session key这个非常重要作为kerberos中下一轮的认证密钥返回给Client由Client的HASH加密的enc-part字段
KDC的AS认证服务在成功认证客户端的身份之后发送AS-REP响应包给客户端。AS-REP响应包中主要包括如下信息
· 请求的用户名(cname)。
· 域名(crealm)。
· TGT认购权证包含明文的版本号域名请求的服务名以及加密部分enc-part。加密部分用krbtgt密钥加密。加密部分包含Logon Session Key、用户名、域名、认证时间、认证到期时间和authorization-data。authorization-data中包含最重要的PAC特权属性证书(包含用户的RID用户所在组的RID) 等。
· enc_Logon Session Key使用用户密钥加密Logon Session Key后的值其作用是用于确保客户端和KDC下阶段之间通信安全。也就是AS-REP中最外层的enc-part。
· 以及一些其他信息如版本号消息类型等。
TGT认购权证
AS-REP响应包中的ticket便是TGT认购权证了。TGT认购权证中包含一些明文显示的信息如版本号tkt-vno、域名realm、请求的服务名sname。但是TGT认购权证中最重要的还是加密部分加密部分是使用krbtgt帐户密钥加密的。加密部分主要包含的内容有Logon Session Key、请求的用户名cname、域名crealm、认证时间authtime、认证到期时间endtime、authorization-data等信息。
最重要的还是authorization-data部分这部分中包含客户端的身份权限等信息这些信息包含在PAC中。
KDC生成PAC的过程如下KDC在收到客户端发来的AS-REQ请求后从请求中取出cname字段然后查询活动目录数据库找到sAMAccountName属性为cname字段的值的用户用该用户的身份生成一个对应的PAC。
Logon Session Key
AS-REP响应包最外层的那部分便是加密的Login session Key了其作用是用于确保客户端和KDC下阶段之间通信安全它使用请求的用户密钥加密。
我们对最外层的enc-part部分进行解密就可以看到是使用hack用户的密钥对其进行解密的。
解密结果如下主要包含的内容是认证时间authtime、认证到期时间endtime、域名srealm、请求的服务名sname、协商标志flags等一些信息。需要说明的是在TGT认购权证中也包含Logon Session Key 作为下阶段的认证密钥。
ticket
这个ticket用于TGS_REQ的认证。是加密的用户不可读取里面的内容。在AS_REQ请求里面是是使用krbtgt的hash进行加密的因此如果我们拥有krbtgt的hash就可以自己制作一个ticket既黄金票据。
3、然后继续来讲相关的TGS的认证过程
KRB_TGS_REQ(请求)
Client 接收到了加密后的ticket(TGT) 和 enc-part 之后先对enc-part用自身密码HASH解密得到Session key也就是上文中说的 随机生成的Session key。
TGT是由KDC中krbtgt的Hash加密所以Client 无法解密。
这时 Client 继续再用Session key加密的TimeStampauthenticator然后再和ticket(TGT) 一起发送给 KDC 中的 TGSTicketGranting Server票据授权服务器换取能够访问 Server 的票据。
然后这里面的ticket其实还是我们的TGT票据这里的enc-part不是上面说的enc-part这里的enc-part(TGT)
KRB_TGS_REP(应答)
TGS 收到 Client 发送过来的ticket(TGT) 和 Session key 加密TimeStamp的 authenticator 之后首先会检查自身是否存在 Client 所请求的服务。如果服务存在则用 krbtgt的HASH来解密ticket(TGT)。
一般情况下 TGS 会检查 TGT 中的时间戳查看 TGT 是否过期且原始地址是否和 TGT 中保存的地址相同。
验证成功之后将返回Client两个东西一个是用 Session key 加密的enc-part然后另一个是 Client要访问的Server的密码 HASH 加密的 TGS票据要访问服务端的Hash生成就是STTGS票据那么此时的ticket就是TGS了
这个过程其实跟我们请求TGT是一样的我就不讲了你可以看到一个ticket(TGS)和一个enc-part
enc-part这个部分同样是可以解密的原因就是这里enc-part加密用的密钥实际上就是上一轮AS_REP里面返回的Session key从开始到现在这里的Session key一直都是一样的作为下一轮通信的认证密钥。
4、cilent访问服务端
KRB_AP_REQ(请求)
到此客户端就可以用 ST 来向服务端发出申请了。客户端向服务器发送类型为 KRB_AP_REQ 类型的消息
发送的信息有如下两个其实就跟上面的流程一样了
1、一个新生成的 Authenticator包括 客户ID 和 时间戳由Session key进行加密
2、TGS(ST)
KRB_AP_REP(应答)
服务端接收后用自己的 Hash 解密 ST获取会话密钥解密获得 Authenticator和ST中的信息对比来确定用户的身份。确定身份后就拿着PAC去KDC那边问Client有没有访问权限域控解密PAC。获取Client的sid以及所在的组再根据该服务的ACL判断Client是否有访问服务的权限到此完成整个认证流程大多数服务并没有验证PAC这一步。
巴拉巴拉铺垫这莫多的知识点我们俩来看一下黄金票据咋个弄
三、黄金票据的原理和条件
1原理
黄金票据伪造的是票据授予票据(TGT)TGTkrbtgt hash(session key,client infoend time)。TGT由AS返回给client然后client用TGT来向TGS验证自己的身份而client是不知道krbtgt hash的只有AS与TGS知道krbtgt hash所以要想伪造TGT就需要知道krbtgt hash。所以攻击者伪造黄金票据TGT的前提是获得管理员访问域控制器的权限并抓取到krbtgt hash。
而session key是由AS随机生成的TGS在收到TGT之前并不知道所以可以伪造。client info和end time也是可以自己定的。所以我们可以伪造由client发给TGS的TGS REQ进而获得server ticket。
2条件
知道域名称、域SID值、krbtgt hash等。
3.黄金票据的局限性
在一个多域AD森林中根域包含全森林管理组Enterprise Admins而如果创建黄金票据的域不包含Enterprise Admins组则黄金票据不会向林中的其他域提供管理权限也就是说否则黄金票据不能跨域信任使用标准的黄金票据仅限于其创建的子域。在单个域Active Directory林中由于Enterprise Admins组会驻留在此域中此时创建的黄金票据不存在上述局限性。
4.绕过黄金票据局限性
最新版本的Mimikatz支持将迁移域的SID历史记录添加到Enterprise Admins组的黄金票据中。这样一旦某个域名的trbtgt hash被获取到就可伪造用户登录到整个森林中的黄金票据对AD森林中的任何域构成威胁。 而在Active Directory林中的信任之间启用SID筛选可以防止上述绕过黄金票据局限性的操作。
5.黄金票据的特点
1 KDC中的TGS不通过读取AD来验证来自client的TGS REQ中的用户账户信息知道TGT超过20分钟这意味着攻击者可以使用禁用和删除帐户甚至是在Active Directory中不存在的虚拟帐户。 2 由于Kerberos的策略是由DC上的KDC设置的所以如果提供票据则系统就会信任票据的有效性。也就是说即使域策略声明TGT只有10小时有效但将TGT中声明的有效期改为10 年那信任票据的有效性期会成为10年而不是10小时。 3 绕过了SmartCard身份验证要求因为它绕过了DC在创建TGT之前执行的常规验证。 4 要求攻击者拥有Active Directory域的KRBTGT密码哈希值从而伪造TGT。 5 Krbtgt hash可用于生成一个有效的TGT使用RC4模拟任何用户访问Active Directory中的任何资源。 6 只要网络可以访问域即使没有加入域在主机上也可以生成和使用黄金票据。
6.黄金票据防御
1 限制域管理员登录到除域控制器和少数管理服务器以外的任何其他计算机将所有其他权限委派给自定义管理员组。这可以降低攻击者访问域控制器的Active Directory的ntds.dit文件。而如果攻击者无法访问AD数据库ntds.dit文件则其无法获取到krbtgt hash。 2 增加更改krbtgt账户的密码的频率。
四、实践
首先假设拿到了域控然后从域控来导出hash之后再进行TGT伪造的操作。 在域控下执行mimikatz命令
1权限提升privilege::debug 2获得krbtgt账户的SID 、krbtgt:hash
回到client执行mimikatz命令
lsadump::dcsync /domain /user:krbtgt /csv (3)生成票据并利用
mimikatz kerberos::golden /domain:域名 /sid:域SID /aes256:aes256_hmac /user:任意用户名 (4)测试 拿到TGT就可以请求任何服务的权限所以就不需要再单独指定需要哪一个服务了只要目标服务支持Kerberos认证我们就可以进行访问而且是具有一定的权限的。此处直接将票据导入内存也可以将票据存到文件中然后在需要使用的时候再导入到内存中。
在cmd中使用klist命令可以查看当前票据这个时候我们就可以访问文件共享等服务了。
这里有个思考题其实我们都拿到了域控的账号和密码为什么还要写黄金票据请参考文章 《内网安全攻防渗透测试实战指南》读书笔记八权限维持分析及防御_内网安全攻防:渗透测试实战指南》读书笔记-CSDN博客
