ThisWindows insane-difficulty machine was quite challenging, but mostly due to its use of some unconventional settings. Breaking in involved many of the normal enumeration and privilege escalation techniques that are used against Windows machines, but some tweaks by the administrator made it more challenging to find out how to even begin. This machine gave me a chance to learn a lot about using some of the standard Impacket tools in new ways, such as using Kerberos tickets along with IPv6. I hope you enjoy this challenge as much as I did!
I navigated my web browser to the target IP address and found a website for a hosting company called Gigantic Hosting. It offered security services for all hosted servers. I found an email address associated with this
sa...@gigantichosting.com, and a phone number
(818) 995-1560.
In the source code of the website I saw an IP
10.13.38.16/ mentioned in a comment alongside HTTrack Website Copier/3.x. It looked like this website had been mirrored from this IP. I tried to connect to it but there did not seem to be any hosts located there.
However when I submitted the form it redirected me to the IP I had seen in a comment in the source code of the website. This comment form had not been updated and was still pointing towards the site it had been copied from (10.13.38.16).
I found one promising article that described how you could use the IOXIDResolver interface to resolve the network interfaces of the the remote host, and even included a python script proof of concept using the Impacket library.
The scan did not take very long, but this time I was able to see many more ports open. This was looking like a real Windows server now with many of the common Windows Server ports open such as 53 - DNS, 88 - Kerberos, 389 - LDAP, 445 - SMB, and 5985 - WinRM.
The zip file was password-protected, but not encrypted. I was able to see that contents, which were a backup of the Active Directory NTDS database. This was a very juicy find, indeed! If I could extract these files, I could potentially get the password hashes of all of the domain users on this machine.
I tried dumping the registry again using the same command and this time it took much, much, longer to output (like everything else on this machine so far!). I was sure that it was working this time!! I used the -s reg option to make it recursively get all keys. I chose HKEY-USER first since it was a likely place to find potential credentials and other useful system information.
Apparently this user never uses this machine, since their default search was MSNSearch. There surprisingly was actually not that much information in this registry dump. I went back and downloaded the entire HKU hive to include information from all users.
None of the .exe versions of winPEAS worked on this machine, so I had to run the .bat instead. I was also denied running the systeminfo command. The .bat version of WinPEAS seemed to be stuck on a loop, so I started poking around in another shell manually using the things it pointed out.
The output had mentioned a few interesting files. The first I checked was C:\Windows\Panther\unattend.xml. These unattend files can often hold plaintext credentials. This administrator had been smart enough to remove his credentials afterwards. It did contain some IPs and MAC information that could have been useful during a normal engagement.
The Network security: LAN Manager authentication level setting determines which challenge/response authentication protocol is used for network logons. This choice affects the authentication protocol level that clients use, the session security level that the computers negotiate, and the authentication level that servers accept.
I tried to get responder to request LM hashes using the --lm argument, but it gave an error telling me to supply a challenge. The instructions on this hacktricks page are not as well written as a lot of others, but at least responder gave a verbose enough error message to fix the problem.
The example on the page did not work because the specified version of Windows Defender was different, but I found two newer versions in the /platform folder. I hoped that one of these would still be vulnerable to this issue.
The hacktricks blog mentioned that I would get the computer account hash, which seemed to be true. It also mentioned to use the crack.sh service to crack it. This is a website that offers cracking services using their pre-computed rainbow tables.
I received an email back from their server very quickly. It only took 32 seconds to find the hash in the rainbow table. Now I just needed to figure out how to use the machine account hash so I did some more research.
Using the template from the blog I was able to dump the hashes from the machine. There were not nearly as many accounts as in the backup! Now that I had the Administrator hash, it was time to crack it.
Thanks to cube0x0 for making such a fun and challenging machine. The harder-difficulty Windows challenges are rare, and I have enjoyed each one of them. This one gave me a chance to learn a lot about using some of the standard Impacket tools in new ways, such as using Kerberos tickets along with IPv6. I look forward to doing more like this in the future!
3a8082e126