In this blog series, we will be performing a walkthrough of interesting domain takeovers that have occurred during pentest engagements. The first part of this series occurred rather recently during an internal penetration test that wasn’t turning up the results I had expected. During the testing process, I was reviewing screenshots of various web services and came across a login portal I hadn’t seen before. The discovered portal was for Zabbix, which is an open-source monitoring software tool for diverse IT components including networks, servers, virtual machines (VMs), and cloud services.
After some quick Google searching to determine if the service could be configured with some default credentials, I was brought to the following Zabbix resource. This resource revealed that the default credentials for the application are “Admin / Zabbix” (The A in Admin is case sensitive).
Through additional research, I came across the following link in which a user “0x616163” already did some of the exploitation below. Once logged into the Zabbix appliance, we can click on the “Scripts” functionality under the Administration menu. The “Scripts” functionality allows a Zabbix user to execute specific commands on the remote host. The screenshot below shows where the user can create a new script.
The screenshot below shows the creation of a new script. In this specific test case, I want to execute a simple “whoami” command. I have also selected the Host Group of Domain Controllers.
As we can see below the script was successfully created. Now let’s get to executing it.
I then navigated to the menu item “Monitoring” and the sub-item “Latest Data” which gives the user access to sort by specific Host Groups. Sorting by the Host Group set within the script creation process, we can see hostnames of systems within that group. Clicking on the hostname will present the user with additional functionality. In this case – we can execute the recently created script.
BAM!
The results from the script are presented to the user. In this case, we are running as NT AUTHORITY\SYSTEM, which is the highest privilege on a Windows machine. At this point, we could re-configure the script to execute a PowerShell command, create a new user (Domain Admin), etc.
Results
This was one of the easiest domain compromises I have come across due to the high level of functionality within the application only to be protected by publicly available default credentials. Organizations that have implemented Zabbix within their environment should look into the following items to prevent unauthorized script execution:
- Unless a business need requires it, ensure the script execution functionality remains disabled
- Change the default password of the Zabbix Admin account
- Restricting which systems can communicate directly with the Zabbix portal
Following these recommendations as well as common best practices for host web applications, organizations will be more secure and set up for future security success.
