0X01 Attack Chain Diagram#
The diagram is quite dense, so I have extracted a few copies to illustrate the selection and direction of the targets.
Collection of information about the supplier
Attack chain related to the supplier.
Selection of the target supplier for this attack.
0x02 Entry Point#
The entry point is quite simple, a vulnerability in Confluence that allows for direct injection of a memory shell.
The system has 360 Total Security installed.
The system is Windows Server 2008, so the hash of this machine is directly exported.
- Username: Administrator
- Domain: WIN-69U1J6S1795
- Password: HNG7%i&RU
0x03 Internal Network#
Initially, I couldn't connect to port 3389, and scanning revealed that it was not open.
It seemed that the port had been changed, so I checked and confirmed it.
tasklist /svc | findstr TermService //First, find the port
netstat -ano | findstr 2956 //Then, find the service corresponding to this PID
I discovered that the port was 53388 and successfully connected.
The IP address is 192.168.1.188.
I scanned the internal network and found some web assets.
WebTitle: http://192.168.43.1:8080/login.action?os_destination=%2Findex.action&permissionViolation=true code:200 len:29508 title:登录 - 技术中心文档管理系统
WebTitle: http://192.168.1.201:8080/login.action?os_destination=%2Findex.action&permissionViolation=true code:200 len:29508 title:登录 - 技术中心文档管理系统
WebTitle: http://192.168.150.1:8080/login.action?os_destination=%2Findex.action&permissionViolation=true code:200 len:29508 title:登录 - 技术中心文档管理系统
However, these internal web assets in the network segment of the VM are not valuable.
At this point, I thought about using password collision to access other machines in the internal network and tried to brute force RDP using fscan.
fscan.exe -m rdp -p 3389 -h 192.168.30.1/24 -user administrator -pwd test123 -o res.txt
But one problem arose: all the RDP ports in the internal network had been changed, so I couldn't find the correct port to brute force.
I tried SMB to see if I could gain access, but unfortunately, SMB was not exploitable.
After attempting to connect via SMB, I found that I couldn't connect because the default public share was enabled on the target machine, allowing connections even with an empty password.
I checked which machine the administrator had logged in from.
To get the IP address of the administrator's origin:
wevtutil qe security /format:text /q:"Event[System[(EventID=4624)] and EventData[Data[@Name='TargetUserName']='administrator']]"|find "源网络"
Based on the IP address of the machine the administrator logged in from, I found that I couldn't access it.
So, the problem is that it seems impossible to move laterally now, as there are no assets available for a breakthrough.
0x04 Reflection#
Things that have been done:
- Reviewed local files, RDP, and the recycle bin to confirm that there are no exploitable files. RDP does not save passwords, and the existing password collision attempts have failed.
All internal RDP ports have been changed, making it difficult to brute force RDP.(Resolved, successfully obtained RDP ports using kscan's fingerprint recognition).- The origin of the administrator has been identified, but I cannot access the administrator's PC.
- There are no third-party services in the internal network that can be exploited.
0x05 A New Hope#
This environment was stuck, and at the time, there was no solution, so it was left idle.
Later, based on a reminder from the defense team, I scanned ports above 40000 in the internal network IP range.
The reason is that after starting, TeamViewer randomly opens a web port above 40000, and if there is an authentication issue, you can directly retrieve the CID and execute RCE through cgi-bin/rpc?action=verify-haras.
I successfully moved laterally by exploiting the TeamViewer vulnerability on some machines.
Pretend there is an image.jpg
0x06 Conclusion#
This is a case worth pondering. Sometimes, it is important to carefully consider which services in the internal network can be exploited. Often, using third-party services can have unexpected effects.