阅读本文前需要补充的知识：域的基本概念，域环境与工作组环境的区别
何谓域渗透，域渗透就是基于windows域环境的渗透，而域渗透设计到的技术，如哈希传递（PTH）票据传递（PTT）委派攻击等，都是基于域环境下的认证机制来实现的，这也是为什么要了解Windows认证机制的原因之一
Windows的认证包括三个部分，用户直接操作计算机登陆账户（本地认证），远程连接到工作组中的某个设备（网络认证），登陆到域环境中的某个设备（域认证）
本地认证十分简单：用户输入密码，系统收到密码后将用户输入的密码计算成NTLM Hash，然后与sam数据库（%SystemRoot%\system32\config\sam）中该用户的哈希比对，匹配则登陆成功，不匹配则登陆失败
这里提到的NTLM哈希，是一种单向哈希算法，Windows将用户的密码计算成NTLM哈希之后才存储在电脑中，对于这个概念一定要牢牢记住，因为后面NTLM Hash会经常出现
大致的运算流程为：
1 | 用户密码->HEX编码->Unicode编码->MD4 |
用python计算密码’admin’的NTLM哈希：
NTLM Hash的前身是LM Hash，由于存在安全缺陷已经被淘汰，无需做过多的了解,知道有这个东西即可
本地认证中用来处理用户输入密码的进程即lsass.exe,密码会在这个进程中明文保存，供该进程将密码计算成NTLM Hash与sam进行比对
我们使用mimikatz来获取的明文密码，便是在这个进程中读取到的
网络认证即在工作组环境下远程登陆另一台电脑所采用的认证机制
NTLM协议的认证过程分为三步，也叫挑战相应机制：
协商：双方确定使用的协议版本，NTLM存在V1和V2两个版本，具体区别就是加密方式不同，不用管
质询：挑战（Chalenge）/响应（Response）认证机制的核心
1.客户端向服务器端发送用户信息(用户名)请求
2.服务器接受到请求后，判断本地用户列表是否存在客户端发送的用户名，如果没有返回认证失败，如果有，生成一个16位的随机数，被称之为“Challenge”， 然后使用登录用户名对应的NTLM Hash加密Challenge(16位随机字符)， 生成Challenge1保存在内存中。同时，生成Challenge1后，将Challenge(16位随机字符)发送给客户端。
3.客户端接受到Challenge后，使用自己提供的账户的密码转换成对应的NTLM Hash，然后使用这个NTLM Hash加密Challenge生成Response，然后将Response发送至服务器端。
验证：在质询完成后，验证结果，是认证的最后一步。
服务端收到客户端发送的Response后，与之前保存在内存中的Channelge1比较，如果相等认证通过
其中，经过NTLM Hash加密Challenge的结果在网络协议中称之为Net NTLM Hash（不能直接用来进行哈希传递攻击，但可以通过暴力破解来获取明文密码）
简单的来说：客户端向服务器请求使用某个用户进行验证，服务端判断该用户是否存在，存在的话使用这个用户密码的哈希值来加密一个随机字符串，并且将这个随机字符串返回给客户端，客户端再把自己提供的密码进行哈希处理后也来加密这串随机字符串，然后再把结果发送给服务器，服务器把从客户端发送的加密结果与自己本地的加密结果进行比较，相同的话便通过认证
其中的关键点在于：第二步中客户端发送的是NTLM哈希值与随机字符串加密的结果，而这个NTLM哈希是由用户输入的密码本地计算得出的，所以在这个步骤中，只要能提供正确的NTLM哈希即使不知道正确的密码也可通过认证
再举个简单的例子，渗透某个站点，通过sql注入获取到了用户数据库，然后发现数据库中的管理员密码是md5加密的而且无法解开，但是这时候发现在前端登录时，也会将你输入的密码进行md5加密，也就是说后端是对比两个md5值是否相同，那我如果知道密码的md5值就能直接登录了，干嘛还要去解开呢？
工作组环境和域环境下Net NTLM认证过程因为有DC（域控制器）的参与流程略有差异，不过不影响我们进行哈希传递攻击
域内认证即采用了Kerberos协议的认证机制，与前两者相比最大的区别是有个一个可信的第三方机构KDC的参与
参与域认证的三个角色：
AD，全称叫account database，存储域中所有用户的用户名和对应的NTLM Hash，可以理解为域中的SAM数据库，KDC可以从AD中提取域中所有用户的NTLM Hash，这是Kerberos协议能够成功实现的基础。
从物理层面看，AD与AS，TGS，KDC均为域控制器(Domain Controller)。
Kerberos认证协议的基础概念：
票据（Ticket）：是网络对象互相访问的凭证。
TGT（Ticket Granting Ticket）：看英文名就知道，用来生成Ticket的Ticket，Ticket的爹。
KDC负责管理票据、认证票据、分发票据，但是KDC不是一个独立的服务，它由以下服务组成：
Authentication Service: 简称AS，为Client生成TGT的服务，也用来完成对Client的身份验证
Ticket Granting Service: 为Client生成允许对某个服务访问的ticket，就是Client从AS那里拿到TGT之后，来TGS这里再申请对某个特定服务或服务器访问的Ticket，只有获取到这个Ticket，Client才有权限去访问对应的服务
Kerbroes认证流程有些繁琐：
Client向KDC发起服务请求，希望获取访问Server的权限。 KDC得到了这个消息，首先得判断Client是否是可信赖的， 也就是从AD数据库中寻找该用户是否可用来登录。这就是AS服务完成的工作，成功后，AS返回TGT给Client。
Client得到了TGT后，继续向KDC请求，希望获取访问Server的权限。KDC又得到了这个消息，这时候通过Client 消息中的TGT，判断出了Client拥有了这个权限，给了Client访问Server的权限Ticket。（TGS服务的任务）
Client得到Ticket后便可以使用这个Ticket成功访问Server。但是这个Ticket只能用来访问这个Server，如果要访问其他Server需要向KDC重新申请。
Kerberos由于容易让人看困，后面单独再拿出一章来讲
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。