In Part 1 of this series, I outlined how during this recent red team test at Anitian, I broke into a client’s network. I researched the company’s employees, conducted a phishing test, obtained information about employees on vacation, and ultimately impersonated this employee to hack the help desk to obtain credentials.
If this was a normal social engineering test, this would be the end. I would write up the findings and recommendations. However, this is a red team penetration test. And as I mentioned in the previous blog, anything goes. Red team penetration tests evaluate an entire security automation program. We were assessing a large corporation we are calling Victim Corp.
How I broke into a client’s network and gained Administrator level access?
In this second part, I will show how I used this single stolen credential to own the entire company.
Stay On Target
As you may remember from the previous blog, I hacked my way into a virtual desktop using stolen credentials of the risk manager, I am calling “John Doe.”
I had access to this virtual desktop along with all the user’s documents. I snooped through the user’s files hunting for passwords. I spotted an enticing looking Word document. Inside were more than 20 account credentials. Oh yeah, this is good.
However, upon deeper inspection, I determined these were John’s personal accounts, such as his 401k, banking, and frequent flier information. Suffice to say, at this point, I had enough data to seriously disrupt John’s life. Tempting.
I must stay on target. I am on a mission to hack the company, not John’s airline miles. I set aside John’s data (which a true blackhat would have used) and kept searching.
SYSVOL pentest active directory
I focused my attention to the local virtual desktop. While there was no obvious path to escalate my user privileges, perhaps I could escalate my local machine privileges?
Considering the size of Victim Corp, I deduced they would need a method to configure the local Administrator password for all corporate systems. One common, but dangerous approach is to use Active Directory group policies. To accomplish this, Active Directory stores the password in an XML file on the SYSVOL share. Every domain controller has this share and all domain users can access and read the contents of the SYSVOL share.
While Microsoft encrypts the password using AES 32-bit encryption, the encryption key is widely available. There are plenty of publicly available tools that can crack this encryption. I guess the system administrators at Victim Corp were unaware of this.
I browsed to \\VictimCorpDC1\SYSVOL and ran a search through all the group policy preferences files for the string “cpassword.” I got four hits.
There were three different encrypted passwords, and each one was for an account named “Administrator”. The heart is racing now. There are various tools you can use to decrypt the ciphertext. I decrypted all three passwords. Then I toggled back to the virtual workstation and tried them.
Sure enough, one worked.
Now I have administrator privileges on my local virtual workstation. Since the password is configured via group policy, I assumed this password would work on other systems as well. With local administrator access, I viewed another user’s files saved on this same virtual machine. Unfortunately, that was a dead-end.
For my next move, I wanted to query the domain controller, but my workstation lacked the Windows administrative tools I needed. Moreover, when I attempted to install them, I got an error. It felt like a dead-end but I was not defeated yet.
Hello Betty – pentest domain controller
I pivoted to the network. I ran some light scans, poking around the local subnet. It was mostly other virtual workstations and the VMWare host. Perhaps I could log in to a few other virtual desktops. I picked a live IP at random and logged in. My “john doe” credentials worked.
This was good news. My stolen “john doe” credentials had remote access privileges to other systems on the network. I tested my stolen local admin password as well. It worked also. I searched through user files on this machine, but I did not find much. However, based on some of the files I saw, the user was likely an IT employee. After a few minutes of investigation, I found that Microsoft’s Remote Administration Tools were already installed. Finally, caught a break.
I used RAT to query the domain controller and download a ton of useful data, including a full list of all user accounts, all domain groups, all accounts in the domain admins group, and all domain computers. I cross-referenced the list of computer names with domain admins. I found two computers whose hostnames matched the employee names. It was a good bet that those two systems were domain administrator employee workstations. One of these systems, BETTY, proved to be extremely valuable in my quest.
Owning the Domain…or Not
I made a remote desktop connection to the BETTY system and escalated my privileges using the local administrator password. I scoured all of Betty’s locally saved documents, hoping that she would have something sensitive since she is a domain administrator. After some time, I located a PowerShell script called simply “script.ps1”. I opened it up and saw a lot of references to VMware. Obviously, this script has something to do with virtual machine management. Embedded in this script, was the following command:
connect-viserver vm1.dev.victimcorp -user admin -password "1qaz@WSX" | out-null
Note this command has been sanitized from the original.
There are a lot of goodies in this one line of code. First, the server hostname has “dev” in the name. It is likely a non-production system and therefore not the kind of system I want to target. However, the username is “admin” and best of all, the password is right there in clear text!
Knowing that the BETTY workstation belongs to an admin who appears to manage this vm1 server, I looked around and found VMware VSphere installed. I loaded that up and connected to vm1.dev.victimcorp. When prompted for credentials, I enter the username and password from the script. They worked. I had access to the VMware host. This was tantalizing.
This host had six virtual machines configured, all with “Dev” in the name. I opened a console to each. Maybe somebody forgot to logout? No such luck. All were logged out.
Hmmm, the last Windows 2012 server listed the last logged in user as “admin”. Did they use the same password for the VMware host and this instance? It is a bad practice, but worth checking. I connected to the system and used the same login and password. Of course, it worked.
After gaining a desktop, I queried the logon server to learn more about my user and the environment. I found out that “admin” was in the domain administrator’s group. This means I had full control over the entire domain! I was on the verge of celebration when I noticed that these systems were all part of a development domain and not Victim Corp’s domain.
Mission not accomplished… Yet.
I created my own domain administrator account on the development domain to hide my activities. I pushed away from the screen and brainstormed ways I can use this new access to take control of the Victim Corp domain.
Hashing Away
I used my domain admin access on the development domain controller to escalate my privileges to SYSTEM. This meant that I had the highest privileges possible on the local Windows system. Using a Meterpreter shell, I dumped the password hashes for all users in the Dev domain. I then cross-referenced the list of users from the Dev domain with the list of domain administrator users in the Victim Corp domain. There were a few overlapping accounts.
I fired up a password cracker to get working on those password hashes. However, I knew from previous projects it can take days to crack a long NTLM password hash. Sometimes, the cracker never gets the password.
Fortunately, well fortunate for me as a hacker, Microsoft Windows lets accounts authenticate to other systems using only the password hash. It is a widely used hacking tactic.
I fired up Metasploit and loaded the PSEXEC exploit. I targeted the Victim Corp primary domain controller. Loaded in my stolen hashes from the dev domain and pounded away on the cross-referenced accounts. It only took a few tries. Boom, I was in.
I logged into Victim Corp’s domain controller using the account “Ads_service” and the same password hash from the Dev domain. This means that the account uses the same password on both domains. This exploit gave me SYSTEM level access to the domain controller.
As Good as It Gets
At this point, I knew I had fulfilled my mission. However, I needed to gather evidence to ensure my work passed peer review at Anitian.
I loaded up the incognito Meterpreter module and listed all the available impersonation tokens. I found there was one left for a user called “bill_adm”. I figured this was likely a domain admin account for somebody named “Bill”. I used Bill’s token to open a shell on the domain controller with Bill’s permissions. Using these rights, I created a new domain user account called “anitian”. Next, I added the new user to the domain admins group.
My new credentials worked perfectly. To provide a bit more evidence, I fired up a remote desktop session to the Victim Corp domain controller. I logged in with ease. I then tried the same VMware Horizon View portal I used initially, and it worked as well.
I now had full remote access to Victim Corp with domain administrator privileges. I could do whatever I wanted, whenever I wanted to. I could install backdoors, ransomware, steal data – anything. This is about as good (or bad, depending on your perspective) as it gets for a hack.
Game Over, Man
It was about 3:00 AM on a Saturday morning when I finally gained full domain administrator privileges on Victim Corp’s network. I was exhilarated but exhausted. I needed some rest. I accomplished the mission.
Six hours later I awoke and stumbled over to my workstation. I wanted to check if my Anitian account still worked. I loaded up the VMware Horizon View and used the credentials I created.
“Your account has been disabled.”
Uh oh. Are they on to me? I tried logging back in as John Doe; that still worked. If they were onto me, they had not linked my activities to the John Doe account. I quickly regained access to the domain controller and created two new domain accounts. One was a domain admin with a deceptive name that matched the service accounts they use internally. The other was a regular user, also with a deceptive name. I figured that they may have somehow been alerted when a domain administrator account was created, but I hoped that they would not know about a normal user account.
I took a break to eat some breakfast. An hour later I tried my two new accounts again. Both were disabled. Ack! They got me. I was prepping for another attempt when the client contacted me.
The game was over. They admitted defeat and asked me to stop. I agreed and took the day off to bask in my success.
More Red Team Testing to Come
Stay tuned for the next installment (you can read part 3 here) and find out how this project concluded. We will analyze the results and provide some valuable lessons learned for our Victim and ourselves. Explore the FedRAMP compliance solution that helps prevent your organization from exploits and vulnerabilities.
