前言

内网的东西太多太杂了,还得总结一下,不然根本记不住

NTLM 认证:

认证过程

用户先输入账号密码登录,客户端先缓存密码的哈希值,密码会被丢弃,当发送请求时,服务端收到请求后生成一个16位的随机数(challenge),这个也会先保存在服务端,然后发送到客户端。

客户端收到后,用之前保存的密码哈希值对他加密,然后把加密的challenge发给服务器

服务器收到后,向dc发送针对客户端的验证请求(主要包括客户端用户名,客户端密码哈希值加密的challenge和原始的challenge)

dc会根据用户名获取改密码的哈希值,然后对原始的challenge加密,然后进行验证,验证成功则通过

Kerberos认证:

粗略流程

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申请

详细流程

先理解一下什么是KDC和TGS,其次也要知道每个计算机名和用户名都对应一个NTLM哈希,可作为参数加密。

接着看过程

第一步:

客户端把身份信息(包括用户名和TGS的一些信息也就是域控的一些信息)发给KDC后,KDC首先会验证信息(比如计算机名,用户名是否在AD里面),通过后,KDC会随机生成一个session key,然后用客户端提供过来的用户名在AD中查找对应的NTLM哈希,再用它来加密。加密后的这一块被叫做AS;然后在用KDC里面一个特殊的用户的hash来加密之前的session key和客户端信息,这一块被叫做TGT,把AS和TGT一起返回给客户端。

再看一下第一步中客户端和服务端发送过去的具体内容

客户端:

服务端:

第二步:

客户端现在拿到了TGT和AS,但是要解密TGT,需要知道KDC中特殊用户(这里就说为KDC吧)的哈希,显然客户端是不知道,所以客户端拿他没有办法,但是客户端有他自己的哈希,所以可以解密AS得到session key,再重新封装信息(请求的服务端信息,时间戳,客户端信息)再用session key加密后的信息和无法解密的TGT一起发送过去

但KDC拿到后会先给TGS服务进行认证,TGS拿到后会先解密TGT里面的内容,因为TGS里面没有储存session key,但是他有KDC的哈希,解密后会得到session key ,再用session key去解密得到用户信息,然后会校验时间戳和两次解密的客户端信息是否相等等,认证通过后KDC会再次随机生成一个不一样的session key(这里把他叫做session key2) 然后KDC会去用session key去加密session key2得到一个数据包,同时找服务器名对应的hash来加密Ticket,相当于得到了两个东西,一个加密后的数据包,一个Ticket再发送回去,Ticket具体内容如下图

第三步:

第二步过后,客户端和KDC的通信过程就结束了,现在是和服务端的通信过程

客户端拿到这两部分后,因为他没有server hash,所以他无法解密Tickst,但是他有session key,所以他先解密数据包的部分,得到server session key也就是session key2,他用session key2加密一个新的与服务端通信的数据包和Ticket发送给服务端

服务端拿到后,因为他是有自己的哈希的,所以他首先解密Ticket,得到sesison key2,然后再解密session key2包装的客户端信息,最后判断解密出来的客户端信息和Ticket里面的客户端信息是否先等,同时判断时间戳是否在允许范围内,认证通过则允许通信。

理解kerberos认证流程会更通透的理解横向移动中的票据工具

白银票据:

白银票据的特点:

1.不需要与KDC进行交互

2.需要目标服务的NMLM Hash

白银票据具体流程:

他主要是截断了第三步认证,再第三步中 Ticket=Server Hash(Server Session Key + Client info + End Time)

也就是说,当我们拥有Server Hash的时候,我们就可以伪造一个不经过KDC认证的Ticket。

仔细来看,当我们拥有Server Hash的时候,我们可以直接伪造一个Ticket,由于服务端是先解密Ticket再获得server session key,再用server session key去解密获得客户端信息的,也就是说服务端开始是不知道server session key的,那我们在Ticket里面随便伪造一个server session key 在加上伪造的客户端信息就可以了,再用我们伪造的server session key 来包装同样的假的客户端信息来让服务端通过验证

白银票据的防御:

1.经历保证服务器凭证不被窃取

2.开启PAC特权属性证书保护功能,PAC主要是规定服务器讲票据发送给kerberos服务也就是KDC,由kerberos服务验证票据是否有效,当经过KDC的时候,伪造第三步肯定就没有什么用了。

开启方式:将注册表中HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaKerberosParameters中的ValidateKdcPacSignature设置为1.

黄金票据

黄金票据的特点:

1.需要与KDC通信

2.需要kebtgt用户的hash

这里的krbtgt hash就是之前说的KDC hash

黄金票据具体流程:

也就是说当获得KDC的哈希的时候,可以直接从第二步开始伪造,同样的,KDC是不知道session key的,他也是要通过自己的哈希来解密TGT后才能获得session key。那我们直接从第二步开始截胡,先把相关客户端信息和伪造的session key用KDC哈希加密来伪造一个TGT,然后再用伪造的session key去加密想要访问的服务端信息,然后就是正常的通信了。

Ticket总结

黄金票据

从工具面来看,获取krbtgt用户的hash后,可以在域中进行持久的隐藏,并且日志无法溯源,但是需要那道DC权限,使用黄金票据能够在一个域环境中长时间控制整个域

从防御角度来看,需要经常更新krbtgt的密码,才能够使原有的票据失效,最根本的办法是不允许域管账户登录其他服务器

白银票据

从攻击层面来看,伪造白银票据的难度比黄金票据小很多,因为一个域中如果服务器对外的话,非常容易被入侵,并且容易被转储Server Hash

从防御角度来看 ,需要开启PAC认证,但是这样会降低效率,增加DC的负担,最根本的还是要加固服务器本身对外的服务。

windows access token:

每台计算机登录都有一个token,但是没有重启的时候主令牌会变成模拟令牌,当攻破一个权限的时候,可以伪造模拟令牌来获取dc(如果dc有模拟令牌的话)或其他模拟令牌来获取更高权限

防御

最后

也就是当获得域内一台机器的权限后,想要访问其他域内的机器但并不知道账号密码或者有其他的限制,但是如果域内开启了kerberos认证,而你恰好可以获取凭证,那就可以借用工具以票据的方式发起通信来完成攻击
而金银票据具体的实现方法可以用mimikatz实现或者其他方法,这里只介绍一下原理,具体实现可以看看其他师傅的文章