From XSS to Domain Admin – Solutions
It’s a long way to the root if you wanna Rock and Roll!
First of all, thank you for the massive attendance at the webinar. That was awesome!
For those who missed it, here you can find a recording of the session.
In this post I will outline the steps taken during the attack demoed in the practical part of the webinar.
If you have any question, please post it in a comment.
Here is the network diagram.
I carried on the attack by performing the following steps:
- The blog was vulnerable to a stored XSS attack, so I put my BeEF-XSS hooking payload there.
- An user from the internal network opened the company blog and the browser session got hooked by BeEF.
- Using the
Host/Get System Infocommand I discovered that the Windows7 machine was running a little outdated java version.
- I used
exploit/multi/browser/java_jre17_provider_skeletonin Metasploit to create a webserver with a malicious Java applet.
- I sent the applet to the hooked browser using BeEF’s
Misc/Create Invisible Iframecommand.
- I got a meterpreter shell on the internal machine as a standard domain user.
- I performed some information gathering about the network configuration and the Active Directory domain.
- Then I started a cmd shell, to gain access to the AD policies files via the special SysVol share on the domain controller.
- Exploiting the default permissions on AD policies I got access to the username and the encrypted password of a local administrator.
- The password is strongly encrypted via AES-256-CBC but security researchers got to know the encryption key, so I just decrypted it by using the
- I started the pivoting phase by routing the traffic from my local machine, through the meterpreter session to the internal network and I collected information using
- I used
exploit/windows/smb/psexecmodule to get a shell on a Windows XP machine. I did this to just gain some time by exploiting older and weaker ciphers and methods. The same attack techniques work on Windows 7 and 8.
- I got access to the cached domain credentials on the machine by using
This is were most of the demos out there would have stopped. You have some cached domain credentials and you can crack them with a dictionary.
But this does not work against strong password so I tried to do something more:
- I found an application run by an user… And I made some damage, by killing the application and deleting it 🙂
- The (simulated) users asked an administrator for help, and the sysadmin opened a remote connection on the client machine.
- I stole the authentication token of the sysadmin’s process and run a cmd shell.
- I performed a halflmchallenge authentication versus a SMB server I created by using Metasploit’s
- Then I cracked the challenge response, using rainbow tables and obtaining the password.
At this step I got access to a domain administrator username and password. I used it by:
- Opening a port forward through meterpreter from my local machine to the domain controller.
- And finally opened an RDP connection!
The Scenario in Hera Lab
In the next few days our students will get this scenario in Hera Lab for free, with a detailed PDF with instructions and solutions to perform the attack.
The students will also gain instructions on how to perform the attack exploiting only the Windows 7 machine and without cracking any password!
September 17, 2014 update: All Penetration Testing Professional students now have access to the lab scenario “From XSS to Domain Admin”. You can visit your Members Area and check under “My labs>Hera” to start the lab.
Active Directory policies are a great tool for systems administrators. They can use them to deploy systems and users preferences, lock down the workstation, secure systems, create users and much more.
By default active directory policies have read permissions granted to the domain users. In this webinar we saw how an attacker can exploit a policy file to get access to a local administrator account‘s credentials and then perform an escalation to a full domain administrator account.