In a recent internal network penetration test I found a slightly less conventional route to get domain administrator privileges. This type of attack is certainly not new but it shows how thinking-out of the box takes a crucial part when comes to penetration testing.
The client that I was facing definitely was not new to internal network penetration tests. They run weekly vulnerability scans. They regularly patch their systems. They perform password audit. They use antivirus on all their systems and they regularly update antivirus signatures. In short they know how to have a good base level of security of their network, also because all these common issues were flagged by previous penetration tests.
Everything began when I started looking at their internal web applications. I found an application called AssetExplorer developed by ManageEngine which was protected by default password. A quick Google search allowed me to login into AssetExplorer as an administrator:
AssetExplorer allows a system administrator to scan their networks and retrieve system information such as versions of the operating system, disk space, RAM details and versions of software installed.
In order to pull this information out of the network, AssetExplorer requires a user account that has sufficient privileges to authenticate and access the operating system of remote hosts. In my case the account was member of the domain administrator group.
With the purpose of exploiting the level of privileges of the domain administrator, I configured a network scan pointing to the IP address of my virtual machine Kali, as shown in the image below.
The reason for scanning my virtual machine was to capture the NTLMv2 password hash that the domain administrator is using to authenticate against hosts inside the corporate network. It is worth mentioning that NTLMv2 hash should not be confused with NTLM hash. Without diving into a much deeper conversation of Windows authentication protocols (Kerberos, NTLM, and Digest) which would require a separate blog post, it is sufficient to say that NTLMv2 hashes do not allow the well-known Pass-The-Hash attack whereas NTLM hashes do. Consequently when the NTLMv2 password hash is captured, an attacker has essentially two options: a) crack it or b) relay it against another host in the network that does not support SMB signing (SMB Relay attack).
For the first option, I created a network share using smbserver.py by Impacket. By doing that, any Windows client accessing the network share would release their NTLMv2 hash. This can be seen in the image below. As soon as I executed the scan against my virtual machine, I managed to capture the NTLMv2 hash.
When the NTLMv2 hash is captured, I attempted to retrieve the clear-text password with John the Ripper, although Hashcat supports this type of hash as well.
Since I did not have much luck in cracking the NTLMv2 hash, also because the client configured that account with a strong password, I decided to move to the second option: SMB relay attack. In order to carry out this attack I used MultiRelay.py of the Responder suite. Before launching the attack, it is important to define our target or in other words where we want to connect with the captured NTLMv2 hash. You should pick up a target that has SMB signing disabled otherwise you will not be able to relay the NTLMv2 hash. Domain controllers usually are not a good target as they enforce SMB signing by default. A quick way to discover systems that do not enforce SMB signing is by using RunFinger.py. Among that list I usually pick a target where at least one domain administrator is currently logged in. Typically Invoke-UserHunter of PowerView provides me with this information.
With the target defined, it was just a matter of launching MultiRelay.py, as shown below, and run the network scan from AssetExplorer.
As soon as the NTLMv2 hash was captured was then utilised against the target, giving me a customised CMD shell as shown below.
At this stage it was possible to run “mimi” which executed Mimikatz in order to retrieve clear-text passwords of the domain administrators from memory.
Conclusion
This blog article does not disclose any new vulnerability but instead shows how domain administrator privileges can be achieved by using a slightly less conventional approach. Internal web applications tend to be omitted, skimmed or sampled when performing internal penetration tests as the focus of the assessment is primarily on network configuration.
It is worth mentioning this type of attack is not limited to AssetExplorer but instead can be performed on any web applications that use domain accounts to authenticate on servers. For example, this includes any vulnerability scanning tools such as Nessus, OpenVAS or Qualys.
The final takeaway is that not following basic security practices like changing the default credentials can easily introduce a new set of vulnerabilities.