Commando VM: Using the Testing Platform

Commando VM: Using the Testing Platform

Windows Offensive VM from Mandiant FireEye

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.

Setting the Stage

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.

Tools Involved

The tools in play that I will be leveraging, which are all packaged with Commando VM are below:

  1. nmap
  2. PowerShell
  3. Metasploit
  4. SharpHound
  5. BloodHound
  6. PowerSploit
  7. Mimikatz

The Attack

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.

PowerShell AD Reconnaissance
PowerShell AD Reconnaissance

Moving on to SharpHound/BloodHound results we can see that the KevinJ account has a session on a few machines, one being KJ12Test.

SharpHound Results
SharpHound Results
BloodHound Visualization of SharpHound Data
BloodHound Visualization of SharpHound Data

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.

nmap Scan Results
nmap Scan Results

So now I have identified some targets to go after:

  1. KevinJ domain administrator account
  2. KJ12Test machine hosting a MS SQL Server

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:

  1. scanner/mssql/mssql_login
    • This will attempt to brute force the sa account with a password dictionary
  2. exploit/windows/mssql/mssql_payload
    • This will abuse the xp_commandshell permissions in SQL to get a system level meterpreter shell

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.

Show Options for the mssql_login Scanner
Show Options for the mssql_login Scanner

The options I’ll be setting for my attack are:

  1. USERNAME – account we want to try to crack
  2. RHOSTS – list of IPs of the hosts we want to run the dictionary attack against
  3. PASS_FILE – location of a password list to use for the dictionary attack
Configuring Options and Exploiting the sa Account
Configuring Options and Exploiting the sa Account

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.

Show Options for the mssql_payload Exploit
Show Options for the mssql_payload Exploit

The options I’ll be setting for my attack are:

  1. PASSWORD – password of the SA account
  2. RHOSTS – list of IPs of the hosts we want to run the payload against

I don’t need to set the USERNAME as the default value is ‘sa’ which is the account we’re going after.

Configuring Options and Exploiting the SQL Server
Configuring Options and Exploiting the SQL Server

Once this completes, we’ll get a system level meterpreter session on the SQL server.

Meterpreter Session Running as SYSTEM
Meterpreter Session Running as SYSTEM

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 sbpmlab\notadmin /add.

Adding my Compromised Account to the Administrator Group
Adding my Compromised Account to the Administrator Group

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.

Attack Path Visualized with BloodHound
Attack Path Visualized with BloodHound

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.

Using PowerSploit and Invoke-Mimikatz, I can get the NTLM Hash Remotely
Using PowerSploit and Invoke-Mimikatz, I can get the NTLM Hash Remotely

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.

Pass-the-Hash Attack Against the KevinJ Account
Pass-the-Hash Attack Against the KevinJ Account

I now have a domain administrator account at my disposal.

To Review

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.

  1. Phishing attack to get a low-privileged domain account
  2. PowerShell reconnaissance to identify Domain Admins
  3. SharpHound to identify sessions on machines
  4. nmap to identify a MS SQL Server
  5. Metasploit to brute force a SQL account with a dictionary attack
  6. Metasploit to exploit the permission xp_commandshell and get SYSTEM level access
  7. Grant local admin access to compromised account
  8. BloodHound to visualize an attack path
  9. PowerSploit to gather a hash remotely
  10. Mimikatz to PtH and take over a domain admin account

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.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Start a Free StealthAUDIT® Trial!

No risk. No obligation.

Privacy Preference Center

      Necessary

      Advertising

      Analytics

      Other