爆破是渗透中常用的一个攻击手法，特别是拿到一个跳板机后，对域的渗透中使用较多。用于爆破的工具比较多，每种工具的实现 *** 也不尽相同。

本篇主要针对Kerberos、LDAP、DCE/RPC、 *** B协议的登陆认证过程进行研究，同时分析认证过程中产生的流量，制定对应的检测规则。

0x01? ? ? ? Kerberos协议

Kerberos是由MIT大学提出的一种 *** 身份验证协议，旨在通过使用密钥加密技术为C/S应用程序提供强身份验证。其实现涉及到密钥分发与密钥共享的概念。

Kerberos是基于对称加密体制(Needham-Schroeder认证协议) 的第三方认证机制，其中用户和服务依赖于第三方（Kerberos 服务器）来对彼此进行身份验证，它有两个版本v4和v5。Kerberos认证时可以使用UDP或TCP协议。

Kerberos主要有三个角色组成

• KDC(服务器本身称为密钥分发中心)
• AS (Authentication Server)认证服务器
• TGS (Ticket Granting Server)票据授权服务器

Kerberos协议认证过程

一共分为6个步骤

1) KRB_AS_REQ：users->AS 发送Authenticator1(users密码加密TimeStamp)

2) KRB_AS_REP：AS->users 发送users密码加密的sessionkey-as 和tgt(kdc密码加密的sessionkey-as和TimeStamp)

3) KRB_TGS_REQ：users->TGS 发送Authenticator2 (sessionkey-as加密TimeStamp) 和tgt(kdc密码HASH加密的sessionkey-as和TimeStamp)

4) KRB_TGS_REP：TGS->users 发送密文1(sessionkey-as加密sessionkey-tgs) 和ST(Server密码HASH加密sessionkey-tgs)

5) KRB_AP_REQ：users->server 发送Authenticator3(sessionkey-tgs加密TimeStamp) 和ST(Server密码加密sessionkey-tgs)

6) KRB_AP_REP：server->users

Server通过自己的密码解密ST，sessionkey-tgs,再用sessionkey-tgs解密Authenticator3得到TimeStamp，验证正确返回验证成功的特征

在进行密码爆破的时候，我们只需利用AS认证过程。

客户端发送AS-REQ

AS响应

• 在Kerberos 5之前，Kerberos允许不使用密码进行身份认证，而在Kerberos 5中，密码信息不可或缺，这种过程称之为“预认证”。可能出于向前兼容考虑，Kerberos在执行预认证之前，首先会尝试不使用密码进行身份认证，因此在登录期间，发送初始AS-REQ后我们总是能看到一个错误信息。

之一次发送空密码的请求

第二次发送带加密hash的请求

认证失败，error-code:eRR-PREAUTH-FAILED(24)

认证成功，直接响应AS-REP并返回tgt

工具：

• kerbrute
• pyKerbrute

日志：

开启日志审核后，会产生Kerberos身份验证服务的日志，成功的事件ID为4768，失败事件ID为4771

• 开启登录事件审核 *** ：命令行输入gpedit.msc打开本地安全策略，”本地策略”、”审核策略” 开启审核登录事件、审核账户登录事件

0x02? ? ? ? ?LDAP协议

LDAP(Lightweight Directory Access Protocol) 轻量目录访问协议。LDAP 协议之前有一个 X.500 DAP 协议规范，该协议十分复杂，是一个重量级的协议，后来对 X.500进行了简化，诞生了 LDAP 协议，与 X.500 相比变得较为轻量，目前最新的版本是LDAP v3(RFC 2251)。

在域内LDAP是用来访问Acitve Directory数据库的目录服务协议。AD DS域服务通过使用LDAP名称路径表示对象在Active Directory数据库中的位置。管理员使用LDAP协议来访问活动目录中的对象，LDAP通过“命令路径”定位对象在数据库中的位置，即使用标识名（Distinguished Name,DN）和相对标识名（Relative Distinguished Name,RDN）标识对象。

LDAP认证过程

• LDAP v2支持三种认证方式：匿名认证、简单身份认证（明文密码）、Kerberos v4。
• LDAP v3使用SASL?(Simple Authentication and Security Layer) 简单身份验证和安全层?身份认证框架（RFC 2222）,它允许使用不同的验证机制对客户端进行身份验证，包括：DIGEST-MD5, CRAM-MD5，Anonymous，External，S/Key，GSSAPI和 Kerberos。SASL指定了质询-响应协议，在该协议中，客户端和服务端之间通过协商确定使用哪种验证机制。

下图是使用LDAP协议的身份验证流程：

1. Client首先发送bindRequest请求给LDAP Server，指定使用GSSAPI认证并且使用NTLM进行身份验证。

2. Server 进行bind响应，包括产生的Challenge

3. Client发送 NTLMSSP_AUTH 认证，请求中包含用户名、认证信息

4. Server认证结果响应

• Server认证通过，响应success，Client可以继续查询操作

• Server认证失败，响应invalidCredentials，之后Client发送unbindRequest结束本轮请求

工具：

DomainPasswordSpray（powershell工具，需要在域环境中使用）

PS C:\Users	est3> Invoke-DomainPasswordSpray -UserList C:\Tools\domain\DomainPasswordSpray-master?txt -Password? admin111 -domain cool.com

日志：

开启日志审核后进行爆破登陆，会产生相应的审核日志：失败，事件ID为4625；成功，事件ID为4624

日志里会记录登陆账号名、登陆IP等信息

0x03? ? ? ? ?DCE/RPC协议

DCE/RPC（Distributed Computing Environment / Remote procedure Call）全称分布式计算环境/远程过程调用。RPC（远程过程调用）有v4、v5两种版本，两个版本的差别很大，现实中已经很难抓到v4的数据，一般遇到的是v5版本的数据。

一个RPC服务可以绑定多种协议序列，如：

• *** B --- ncacn_np (固定的139、445/TCP)
• TCP --- ncacn_ip_tcp (动态TCP端口)
• UDP --- ncadg_ip_udp (动态UDP端口)
• HTTP --- ncacn_http
• 其他协议

可以将DCE/RPC看作一层，上层协议可以是上述协议中的一种。实际上还有其他协议序列可用，但不常见，就不细说了。

ncacn_ip_tcp与ncadg_ip_udp用到了动态端口，它们会向EPM接口注册所用动态端口，而客户端可以向EPM接口查询服务端注册过的信息(EPM接口本身也是一个RPC服务，同样有多种协议可以用来访问这个接口)。

无论使用哪种协议序列，访问一个RPC接口的都必须有Bind、Request请求。但是不同的协议序列，就会有不同的bind响应、request响应

协议栈解码过程如下：

认证过程（使用TCP协议绑定）：

1）首先客户端发起Bind请求，请求绑定EPM Interface

服务端响应Bind_ack，收到Bind_ack报文并不意味着Bind成功，需要根据Ack result字段判断:

• 0 Acceptance #Bind成功
• 2 Provider rejection #Bind失败

2）客户端调用EPM接口发起Request请求( *** B调用的是samr接口)，与服务端协商接下来使用的动态端口。

服务端收到请求后，将生成的随机端口响应给客户端

3）客户端使用协商好的端口发送AUTH3认证请求，认证方式为NTLM，请求中包含用户名及认证信息

AUTH3请求后如果口令错误并不会立即得到验证，可以通过接下来的Connect request请求的响应来判断。

认证成功，发起的Connect request 会有对应的Connect response响应

认证失败没有Connect response响应，而是直接返回Packet type: Fault且Status为nca_s_fault_access_denied的响应

工具：

网上没有找到现成的工具，利用impacket写了一个简单的爆破工具(非域内主机可以使用)

日志：

开启日志审核的话会产生登陆日志

• 登录失败：产生事件ID为4625的登陆日志
• 登陆成功：产生事件ID为4624的登录日志

0x04? ? ? ? ? *** B协议

*** B(Server Message Block)服务器消息块，又称 *** 文件共享系统(Common Internet File System，缩写为CIFS)，可用于计算机间共享文件、打印机访问。 *** B消息一般使用NetBIOS（一般是139端口，很少使用137、138端口）或TCP协议（445端口）发送。

*** B协议支持 NTLM和较早的LAN Manager(LM) 加密，后者由于安全性较低，容易被破解，已经很少使用。

*** B协议登陆认证过程如下：

1. 协商

首先客户端发送Negotiate Request。在请求中，客户端会列出所有它所支持协议版本以及所支持的一些特性（比如加密Encryption、持久句柄Persistent Handle、客户端缓存Leasing等等）。

而服务端会在回复确定协商的认证方式及版本号，并且会以支持的更高版本作为回应。

2. NTLM challenge/response

由于1中协商使用NTLM认证，接下来执行NTLM的认证过程。客户端通过Session Setup发送NTLMSSP_NEGOTIATE请求

服务端对相应的请求进行响应，其中包括产生的challenge

3. 身份认证

客户端发送登录认证请求，附带用户名、加密hash

服务端对hash进行校验：

校验成功：NT Status: STATUS_SUCCESS

校验失败，NT Status：STATUS_LOGON_FAILURE

工具：

acccheck （kali自带工具）

Metasploit: auxiliary/scanner/ *** b/ *** b_login

使用 *** B协议进行密码爆破，攻击机可以在非域环境中。

日志：

登陆失败，事件ID：4625

登陆成功，事件ID：4624

0x05? ? ? ? ?总结：

根据上述几种协议登陆审核日志来看，事件ID跟认证方式（Kerberos，NTLM）有关，跟协议无关（LDAP、 *** B、RPC事件ID相同）。

利用Kerberos、DCE/RPC、 *** B协议进行爆破的时候，攻击机可以在非域环境中，且利用DCE/RPC协议在攻击的时候由于使用了动态端口，从流量层面上来说被安全设备检测的概率会小一些。

检测 *** ：

• 登陆日志

爆破行为会在短时间内产生大量的审核失败的登陆日志

• 流量特征

根据上述几种协议中认证失败的流量特征，对相同源IP、目的IP的失败次数做统计，超过阈值告警。

防御 *** ：

限制登陆错误次数，超过阈值后锁定账户。具体操作如下：

打开“组策略管理”,“Default Domain Policy”,”编辑”

依次点击“计算机配置”，“策略”，“Windows设置”，“安全设置”，“账户策略”，“账户锁定策略”，对锁定阈值进行配置。?

参考文档：

http://woshub.com/hot-to-convert-sid-to-username-and-vice-versa/

https://www.attackdebris.com/?p=311

https://ldapwiki.com/wiki/SASL

https://docs.oracle.com/javase/jndi/tutorial/ldap/models/v3.html

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms- *** b/495dd941-0776-48aa-aa8a-f1aa5eeadcea

http://davenport.sourceforge.net/ntlm.html