Previously, I wrote a high-level overview of the testing platform Commando VM and an installation guide to get started with it. Today, I’ll be diving into a proof of concept of sorts to show off some of the tools and flexibility that the testing platform offers. My goal with this post is to highlight some things that can be done with the platform, situations enterprises should try to be wary of, and some ways enterprises can identify and prevent some of these situations.
To start, I need to set the stage with the fictitious situation I’ve created and set myself in. We can assume I’ve taken over the account ‘notadmin’, a non-privileged account, in the SBPMLAB domain. How I came to take over this account is entirely up to your imagination, but if you need some help, let’s say I phished it through an email phishing campaign.
The tools in play that I will be leveraging, which are all packaged with Commando VM are below:
Now let’s dive into the attack and the scenario at play that I’m using to go from a non-privileged account to a domain administrator. Bear with me, as this is going to be somewhat long and verbose.
First, I’ll need to do some reconnaissance. I have access to the ‘notadmin’ account and was able to download some tools that I am able to use. My first step is to identify some targets. Using SharpHound, PowerShell and nmap, I’m able to identify some things that I want to go after within the SBPMLAB domain. First, let’s take a look at some of the PowerShell and SharpHound results. Running a simple Get-ADGroupMember ‘Domain Admins’ | select name, samaccountname will get me a list of all the direct members of the Domain Admin groups. This will help me identify some targets I may want to go after. The KevinJ account is my target in mind, and we’ll see why in a second.
Moving on to SharpHound/BloodHound results we can see that the KevinJ account has a session on a few machines, one being KJ12Test.
Now that I have a target server in mind, let’s look at nmap. For POC purposes I’ve scoped down my scan to look for a SQL server on port 1433. Using the command nmap 192.168.15.36 -sV -p 1433 I’m able to look for any services running on the port 1433 for the target machine 192.168.15.36 (KJ12Test). Obviously, in a real-world scenario, the scope of a nmap scan would be much larger, you’d more likely scan the entire network to identify any vulnerable services or open ports that exist.
So now I have identified some targets to go after:
Moving on to the next tool, Metasploit, I’m going to look towards exploiting the MS SQL Server application on KJ12Test. Metasploit offers a ton of pre-packaged exploits for all sorts of applications, protocols, operating systems, etc. The two I’ll be using today are:
As you can see below, the mssql_login scanner has some options we can set to streamline the approach of brute forcing the sa accounts password.
The options I’ll be setting for my attack are:
Above you can see after a few attempts, I was able to successfully login to the sa account with a password from the dictionary, P@ssw0rd123. This now means I have a SQL account for the SQL server that is normally privileged and has a copious amount of permissions. Now that I have this account, it leads me into the next attack I’m going to leverage using Metasploit. The mssql_payload exploit has a few options I’ll be setting as well.
The options I’ll be setting for my attack are:
I don’t need to set the USERNAME as the default value is ‘sa’ which is the account we’re going after.
Once this completes, we’ll get a system level meterpreter session on the SQL server.
The next step in the process, is to add myself to the local administrator group on the SQL server. I can spawn a SYSTEM level command prompt by using the command shell in meterpreter. Once that occurs, I can run the command net localgroup administrators sbpmlabnotadmin /add.
The purpose of granting myself local administrator privileges is so I can run Mimikatz and gather the hash of the KevinJ account that has a session on KJ12Test (there are more streamlined ways to do this through Metasploit, but the path I’m choosing to go down shows off the flexibility of Commando VM). Once I’m a local administrator, I rerun SharpHound and BloodHound just to make sure the attack path I thought I was capable of exploiting, still exists. Lo and behold, it does.
Now that I know the attack path I should leverage to compromise the domain administrator account KevinJ. I can use PowerSploit to get the hash of KevinJ remotely, from the machine I’m on.
Now that I have the hash, I can use Mimikatz and run the command sekurlsa::pth /user:kevinj /domain:sbpmlab /ntlm:78fbdcb6b6b069c68296a3543b1a6ebb on the remote machine to pass-the-hash and spawn a command prompt as KevinJ.
I now have a domain administrator account at my disposal.
Now that you’ve made it this far, let’s review what was done during this attack, and what can be done to prevent some of these things from occurring.
Understanding that these situations may exist in your environment is important for blue and red teamers. If situations like this exist in your domain, the red team is bound to exploit them. However, if blue teamers are leveraging testing platforms like Commando VM and the tools that come with it, they may be able to stay one step ahead of the red team, by locking these things down before they get exploited. Not only is it import for the blue team to identify that these things exist and fix them, it’s equally important to ensure they STAY fixed.
So, what can organizations do to prevent some of these situations from existing or occurring?
Phishing – Train your employees on social engineering, the first line of defense is them. If they’re knowledgeable of these tactics, they can help prevent a lot of the unwanted access to your environment.
LDAP Reconnaissance – Monitor LDAP traffic in your environment. Understand who is querying privileged groups and potentially gathering information. StealthDEFEND for Active Directory can help monitor and alert on suspicious LDAP traffic occurring.
Weak Passwords – Ensure your employees are leveraging strong passwords across Active Directory and SQL. StealthAUDIT for Active Directory, StealthAUDIT for SQL, and StealthINTERECEPT Enterprise Password Enforcer can all assist in monitoring and checking for weak passwords set in your environment by comparing them to known compromised passwords commonly found in attacker dictionaries.
SQL Permissions – Understand and limit who can leverage SQL permissions like xp_commandshell. This is important to securing your SQL servers. StealthAUDIT for SQL highlights instances of the xp_commandshell permission existing across all of your MS SQL servers.
Local Administrators – Understanding who your local administrators are across all of your Windows endpoints is important to locking them down and ensuring only the correct users have privileged access. StealthAUDIT for Windows is able to collect and report on all local administrators across your endpoints.
Kevin Joyce is a Senior Technical Product Manager at Stealthbits – now part of Netwrix. He is responsible for building and delivering on the roadmap of Stealthbits products and solutions.
Kevin is passionate about cyber-security and holds a Bachelor of Science degree in Digital Forensics from Bloomsburg University of Pennsylvania.
Proper data security begins with a strong foundation. Find out what you're standing on with a free deep-dive into the security of your Structured and Unstructured Data, Active Directory, and Windows infrastructure.Read more
Start a Free Stealthbits Trial!
No risk. No obligation.
Leave a Reply