7.内网渗透之windows认证机制

文章参考自三好学生域渗透系列文章

看了内网渗透第五篇文章，发现如果想要真正了解PTT，PTH攻击流程，还需要了解windows的认证机制，包括域内的kerberos协议。

windows认证机制

在域渗透中，横向移动最重要是对windows认证协议的理解

首先介绍一下windows密码的Hash:

早期SMB协议在网络上传输明文口令，后来出现"LAN Manager Challenge/Response"验证机制，简称LM，由于容易被破解，微软提出了windows NT挑战/响应机制，称之为NTLM。现在已经有了更新的NTLM v2以及Kerberos验证体系。windows加密过的密码口令，我们称之为hash，windows的系统密码hash默认情况下一般有两部分组成：LM-hash，NTLM-hash 。

NTML hash:

在windows系统中比较常见的是从系统导出来的NTLM hash，通过Hashcat能够破解出明文密码。NTLM hash通常是指windows系统下Securtiy Account Manager中保存的用户密码hash。在渗透测试中，通常可从windows系统中的SAM文件和域控的NTDS.dit文件中获得所有用户的hash，通过mimikatz读取lsass.exe进程能获得已登陆用户的NTLM hash。

NET-NTLM hash:

通常是指网络环境下NTLM认证中的hash

NTLM认证采用质询/应答（Challenge/Response）的消息交换模式，流程如下：

客户端向服务器发送一个请求，请求中包含明文的登录用户名。服务器会提前存储登录用户名和对应的密码hash
服务器接收到请求后，生成一个16位的随机数(这个随机数被称为Challenge),明文发送回客户端。使用存储的登录用户密码hash加密Challenge，获得Challenge1
客户端接收到Challenge后，使用登录用户的密码hash对Challenge加密，获得Challenge2(这个结果被称为response)，将response发送给服务器
服务器接收客户端加密后的response，比较Challenge1和response，如果相同，验证成功

在以上流程中，登录用户的密码hash即NTLM hash，response中包含Net-NTLM hash

更多NTLM认证的资料可参考：

http://davenport.sourceforge.net/ntlm.html

在NTLM认证中，NTLM响应分为NTLM v1，NTLMv2，NTLM session v2三种协议，不同协议使用不同格式的Challenge和加密算法

所以也就存在不同协议的Net-NTLM hash，即Net-NTLM v1 hash，Net-NTLM v2 hash

NTLM认证

在工作组中使用的ntlm认证，如果在域中，则使用Kerberos的认证方式

工作组中：

客户端发起认证请求

服务端收到认证请求，向客户端发送随机数（chanlleng/挑战）

客户端使用NTLM Hash打乱该随机数，生成Net-NTLM Hash，发送回服务端（这里会造成pth攻击）

域环境中：

比起工作组，域中多了一个域控的角色

首先在client输入username，password和domain，然后client会把password hash后的值先缓存到本地

之后，client把username的明文发送给server(DC)

DC会生成一个16字节的随机数,即challenge(挑战码),再传回给client

当client收到challenge以后，会先复制一份出来，然后和缓存中的密码hash再一同混合hash一次,混合后的值称为response，之后client再将challenge，response及username一并都传给server

server端在收到client传过来的这三个值以后会把它们都转发给DC

当DC接到过来的这三个值的以后，会根据username到域控的账号数据库(ntds.dit)里面找到该username对应的hash，然后把这个hash拿出来和传过来的challenge值再混合hash

将上一步混合后的hash值跟传来的response进行比较,相同则认证成功，反之，则失败，当然，如果是本地登录,所有验证肯定也全部都直接在本地进行了

Kerberos协议

在域环境中，Kerberos协议被用来作身份认证，下图是详细的认证过程：

这里仅介绍几个名词：

KDC(Key Distribution Center)：密钥分发中心里面包含两个服务：AS和TGS
AS(Authentication Server)：身份认证服务
TGS(Ticket Granting Server)：票据授予服务
TGT(Ticket Granting Ticket)：由身份认证服务授予的票据，用于身份认证，存储在内存，默认有效期为10小时
Pass The Ticket：如果我们能够拿到用户的TGT，并将其导入到内存，就可以冒充该用户获得其访问权限

详细认证过程，分为三个步骤：

第一:从AS服务器中获取TGT票据
用户在客户端输入账号和密码之后，会对密码进行hash处理，作为user-secret-key
1. 客户端将用户名发送给AS服务器申请服务,在AS服务器中会对用户名进行验证，在AS服务器本地数据库中查询到该用户名的密码，并使用hash生成user-secrect-key.
2. AS服务器向用户发送两样东西：
   1） Client/TGS会话密钥，使用user-secrect-key进行加密
   2） TGT，包含TGS会话密钥，用户信息，时间戳，TGT有效期。使用TGS密钥进行加密
3. 用户接收到消息之后，回使用本地的user-secret-key对消息1)进行解密，如果解密成功，说明用户提供的凭证是正确的,此时用户得到了加密后的TGT。

第二:从TGS服务器中获取访问权限
1. 客户端向TGS服务器发送信息：
   1） 第一步骤中的TGT
   2） 认证信息（认证符(Authenticator)），包含用户id以及时间戳，通过TGS会话密钥进行加密。
2. TGS服务器收到消息之后，会使用TGS密钥对消息1）进行解密,获取到TGS会话密钥，进而对消息2）进行解密，在对用户id以及时间戳进行认证，如果认证成功，向客户端发送消息：
   1） client-server-ticket(包含SS会话密钥，用户名信息以及时间戳)，使用ss密钥进行加密
   2） ss会话密钥使用TGS会话密钥进行加密
3. 客户端收到信息之后会对消息2）进行解密，获得ss会话密钥。

第三：访问服务
1. 客户端向ss服务器发送以下消息：
   1）第二步骤中的client-server-ticket
   2）新的Authenticator，包含用户信息，时间戳。通过SS会话密钥进行加密
2. SS服务器收到消息之后，会使用ss密钥对消息1）进行解密，解密之后使用ss会话密钥对消息2）解密，解密成功之后会得到authenticator，认证之后，发送：
   1）新时间戳，Client发送的时间戳加1，通过ss会话密钥进行加密
3. 客户端收到时间戳之后，解密确认，成功之后发送服务请求
4. ss服务器收到之后提供服务。

到这里，windows基本认证步骤完成了，横向移动的手法请移步我的第五篇文章

posted @ 2019-04-17 14:42 bmjoker 阅读(2969) 评论(3) 编辑收藏举报

刷新页面返回顶部

bmjoker's blog