来自帅气学弟得经验

阅读流程

windows系统认证包括**本地交互式认证 **和 网络认证

交互式登录：向本地计算机或域账户确认用户的身份
网络登录：对用户尝试访问的网络服务或资源提供用户认证

若是本地用户本地认证需要了解**windows密码 **，**加密算法 **和 **认证流程 **
若是内网交互认证需要了解 **挑战/响应机制和哈希传递 **
网络认证则需要掌握域认证Kerberos

windows密码

安全账户管理器SAM（Security Account Manager）机制
SAM存储路径：%SystemRoot%\system32\config\sam
windows本身不存储用户的明文密码，而是存储口令的单向散列（Hash）值

本地认证流程

1.winlogon.exe 登录框

Windows Logon Process（即winlogon.exe）是windows NT用户登录程序，管理用户登录登出

2.lsass.exe 接受用户输入

lsass是微软windows系统的安全机制，用于本地安全和登陆策略

3.获取明文口令对应的Hash值
两种方法：

LAN Manager（LM）：最早使用的密码哈希算法之一
NT LAN Manager v2（NTLMv2）

4.将加密后的Hash与SAM数据库中的Hash进行比较。

比较结果相同将User SID与Group SID 发送给winlogon.exe 准备登录界面
不同则登录失败

Hash算法

LM Hash

LM-Hash算法

密码的LM哈希步骤

将用户口令中的字母全部转换为大写，再将口令的十进制ascii码转成16进制
若口令不足14个字符，后面用0填充；否则通过截断保留前面14个字符。
将14个字符平均分为长度为7的两组。
7字节的两组分别经str_to_key()函数处理，得到两个包含奇偶校验位的DES密钥，即每个都是8字节，64比特。

str_to_key()函数：

将两组16进制转化为比特流，不足56bit则在左边加0。
将比特流按照7比特一组，分出八组，末尾加0
将每组比特流转换为16进制作为密钥，使用DES加密固定字符串，得到八个结果
八个结果转为16进制，拼起来得到hash

分别用两个DES密钥加密一个预定义的8字节魔术字符串（KGS!@#$%），得到两组8字节密文。
两组8字节密文值链接组成16字节（128bit）的值，即为LM哈希。

图解

LM Hash的安全性缺陷

DES算法的密钥太短（56bit）
无法抵御暴力破解。虽然口令有14位，但是两组7位是独立的，且不区分大小写，可能性只有697种。
若口令长度<=7，第二部分固定为0000000，最终的哈希值为固定值（0xAAD3B435B51404EE），因此很容易确定密码长度范围。
Hash值在通过网络发送到服务器时，没有进行salting操作，容易遭受中间人攻击和重放攻击。

NT-Hash算法

NTLMv2

步骤：

1.先将明文口令（Ascii）进行16进制编码（Hex）
2.再将16进制转换为Unicode字符串
3.对Unicode字符串，使用MD4算法，产生固定长度的128bit哈希值。（口令多长，产生的哈希值都是128bit）

补充：

Unicode码用16位表示，也就是两个字节，即4个16进制数。
ASCII码用8位标识，即1个字节，2个16进制数。
ascii码范围内的字符，十六进制的ascii码与unicode码的数值相同。
所以比如字符’1’的ascii码十进制是49，即16进制位0x31，此时用unicode码表示就是0x0031
在NT-Hash算法中将ASCII字符串转换为Unicode字符串时，使用小端序，即低字节放在低地址。0x0031，31是低字节，要放在低地址（左边），所以：3100

挑战/响应机制

NTLM协议

早起SMB协议在网络上传输明文口令。后来出现LAN Manager Challenge/Response 验证机制，简称LM，但他过于简单以至于很容易就被破解。
后来，微软提出了WindowsNT 挑战/响应机制。称之为NTLM，现在还有NTLMv2以及Kerberos验证体系。

C/R

开始前通常还会有协商步骤：即客户端向服务器确认协议的版本，是V1还是V2等等信息。

用户输入Windows账户和口令登录客户端主机。在网络登录前，客户端会缓存输入口令的Hash值，明文口令被丢弃。成功登录的用户如果试图访问服务器资源，则向服务器发送请求，该请求中包含明文的用户名。
服务器收到请求后，生成一个16位随机数，该随机数被称为挑战或Nonce，服务器将挑战以明文的形式发送给客户端。
客户端用步骤1中保存的口令哈希值作为密钥对挑战进行加密，然后把加密后的挑战作为响应发送给服务器。
服务器收到响应后，向域控制器DC（Domain Controller）发送针对该客户端的验证请求，请求包括该客户端的用户名、原始的挑战（随机数的明文）、和从客户端返回的响应（随机数的密文）三部分。
DC根据用户名获取账号数据库中的口令哈希值，并对原始挑战进行加密，如果得到的加密值与服务器发送的响应值一致，则意味着用户拥有正确的口令，验证通过。否则，验证不通过。DC将验证结果发送给服务器。
服务器将验证结果反馈给客户端。

NTLM V2

哈希传递 Pass The Hash

什么是哈希传递？
哈希传递是能够在不需要账户明文密码的情况下完成认证的一个技术。它使用用户名对应的NTLM Hash将服务器给出的Chanllenge加密，生成一个response来完成认证。
在内网渗透中，我们常常需要抓取管理员的密码、NTLM Hash来进行下一步渗透，他能帮助我们解决渗透中获取不到明文密码、破解不了NTLM Hash而又想扩大战果的问题。
NTLM协议其实就是哈希传递的一种实现
smbmap smbexec crackmapexec matasploit都可以用来pth

域认证 Kerberos

Kerberos是一种网络认证协议，其设计目标是通过密钥系统为客户机/服务器应用程序提供强大的认证服务。
该认证过程的实现

不依赖于主机操作系统的认证，
无需基于主机地址的信任，
不要求网络上所有主机的物理安全，
并假定网络上传送的数据包可以被任意地读取、修改和插入数据。

在以上情况下，Kerberos 作为一种可信任的第三方认证服务是通过传统的密码技术(如:共享密钥也就是对称加密)执行认证服务的。相比于NTLM 它多了个中间信托机构。

域认证的三只狗头代表着 Client Server KDC

域认证粗略流程

12 client向kerberos服务发送请求，希望获得访问server的权限。kerberos服务得到了这个消息，首先判断client是否是可信赖的，也就是白名单黑名单的说法。这就是AS服务完成的工作，通过在AD中存储黑名单和白名单来区分client。成功后AS返回TGT给客户端。(AS_REQ与AS_REP)
34 client得到TGT后，继续向kerberos服务请求，希望获得访问server的权限。kerberos服务得到了这个消息，这时通过client消息中的TGT，判断出了client拥有这个权限，于是给了client访问服务端的权限并返回了ticket。(TGS_REQ与TGS_REP)
56 client得到ticket后，终于可以访问server。这个ST只是针对这个server，其他server需要向TGS申请。(AP_REQ与AP_REP)

AD account database 存储所有client白名单，只有存在于白名单的client才能顺利申请TGT
AS 为client生成TGT服务
TGS 为client生成某个服务的ticket

详细拆解每一步

12 得到 client hash（session Key）、KDC hash（TGT）

1 首先客户端会向域控KDC服务上的AS发送我们客户端的一些信息，比如用户名，主机名等。
2 KDC服务上的AS就会判断这个主机是否在我们的域里面，如果存在，那么KDC上的AS就会生成一个session key（一串随机字符）。
3 域控上AD存储了所有用户密码的NTML Hash，上一步验证通过后会使用这个客户端用户对应的NTLM hash来加密我们的session key，并将加密后的值返回发送给客户端。
4 域控使用KDC特殊用户的NTLM hash，对session key和一些客户端的信息进行加密，最后加密出的结果也就是我们常说的TGT，返回给客户端
我们再来用两张图详细的剖析下上面所说的"客户端发送"与"KDC返回"这样的两个过程：
发送：

返回：

34 发送请求信息得到Server Session KEY和ticket

1 我们的客户端接收到了一个密文和一个TGT
2 第一个密文是KDC用我们客户端用户密码的NTLM hash加密session key产生的，因为这个客户端的用户的密码的NTLM hash不仅在域控上存在，在我们客户端本机也是存在的，所以的客户端就会使用这个客户端的用户的密码的NTLM hash来对密文进行解密，从而得到session key。
3 下一步我们的客户端就会向KDC上的TGS服务发送请求信息，包括TGT以及用session key加密的当前客户端的一些信息和时间戳，还有一些客户端的信息和要访问的服务端的信息这三块内容
4 当我们客户端向KDC发送以后，KDC的TGS服务就会开始进行认证，它首先会使用KDC服务对应的用户的NTLM hash去解密TGT得到session key，再通过session key去解密客户端包装加密的信息，得到客户端的一些信息和时间戳，然后会比较这个时间戳和当前的时间戳是不是间隔的太久了，如果间隔超过一定时间则需要他重新从头开始验证。
5 当KDC上的TGS认证通过以后呢，他又会随机生成一串字符，叫做server session key，这个server session key其实就是用于客户端和服务端进行通信时的密钥。TGS会使用session key来加密这个server session key并将这个密文返回给客户端。
6 TGS还会提取客户端的所在的域的域名，客户端的用户信息，server session key,到期时间等做成ticket，TGS还会提取接收到的要访问的服务端的一些信息，并使用服务器端对应的计算机名对应的NTLM hash来加密ticket，并将这个密文也返回给客户端。

ticket组成

56

1 客户端通过session key解密得到server session key，并使用server session key来加密客户端的信息和时间戳，并连同ticket一同发给服务端
2 因为服务端这台机器上是存着自己的用户hash的，所以我们可以使用Server hash解密得到ticket里的内容，通过end time来判断得到的ticket是否已经过期，还会得到ticket里的server session key，然后会使用这个server session key来解密1步骤的密文，得到客户端的信息和时间戳，并去校验这个客户端信息和ticket里的客户端信息是否相等，还会验证这个时间戳是否大于某个时间。

白银票据

特点

1.不需要与KDC进行交互即直接拿ticket与服务端交互（跳过域认证前两步）
2.需要目标服务的NTLM Hash 即Server Hash

伪造

Mimikatz
kerberos::list #列出票据
berberos::purge # 清除票据
假设在域里已经拿下了某台服务器，但这台服务器提供的某些服务需要域认证，我有这台服务器权限就可以导出hash，导出的hash里有server hash用来伪造白银票据，可以解决没有域账户但是仍然想与这台服务器进行认证以进行某些操作的问题。
导出该计算机名对应的hash：

防御

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

黄金票据

特点

1.需要与DC通信
2.需要krbtgt用户的hash 即KDC hash
因为在下一步请求时 TGS是没有session Key的 TGS的session Key是从TGT来的

伪造

MSF kiwi

PAC

在黄金/白银票据的构造分析中，说了开启PAC可以防止白银票据的攻击。

那么PAC是什么呢？
我们都知道黄金票价的构造原理就是：掌握KRBTGT用户密码之后可以通过签发一张高权限用户的TGT票据，再利用这个TGT向KDC获取域内服务的ticket来实现对域的控制。那么这里的“高权限用户”是通过什么来判断的呢，答案就是PAC。

PAC在我们域认证中出现的节点是在哪的呢？
主要是两个节点：
1 当我们的客户端第一次向KDC去请求TGT的时候，我们返回的TGT票据中就包含了PAC。(AS_REP)
2 就是最后我们的客户端拿着ST去与服务端通信的时候，如果一切验证顺利，那么最后我们的服务端就会将解密出来的PAC发送给KDC去进行认证，KDC解密PAC。获取Client的sid，以及所在的组，再根据该服务的ACL，判断Client是否有访问服务的权限。防止白银票据其实主要也是这一步。 (AP_REP)