Top 5 Simple Ways I Became Domain Administrator on your Internal Network and How to Prevent them from Happening (Part 1 of 5)
May 6, 2011 | Posted in Red Teams by Chris Salerno
Your internal network is open to attack. Having done over thirty internal penetration tests and obtained domain/enterprise administrator access on each one, a pattern begins to develop. This series lists the top five simple ways we see internal networks become compromised. These attacks all start from the prospective of an outsider or someone that has simply plugged in to the internal network. These attacks are not sophisticated and require only the use of tools and techniques that are freely available to anyone with a laptop and an Internet connection. This is by no means an extensive list, but if you can successfully mitigate against these easy footholds, your internal network will be significantly more secure than it is right now.
1. The ‘SA’ account on one or many of your SQL Servers is blank or easily guessable
Yes, many of you are already skipping over this explanation because you’ve seen this finding in a penetration test or even a vulnerability scan since 1999. However, it is number one on the list for a reason; it’s everywhere and still one of the quickest and easiest ways to get administrative access on an internal network. The ‘SA’ account on your SQL server database gets special privileges including the ability to execute operating system commands. Protecting this account from compromise is the first step in preventing your SQL servers from becoming an entry point for an attacker.
How the attack works:
- Locate all the SQL Servers on the network (yes, even the ones that aren’t running on 1433) by sweeping the domain for the listening SQL server service
- Identify SQL Server versions and split them into groups: SQL Server 2000, 2005, 2008. SQL Server 2000 can be brute forced with unlimited attempts against the SA account, while 2005 and 2008 may be a little more restrictive and can have account lockout configured (not likely, but we like to take a risk-based approach)
- Scan all visible SQL Servers for blank or weak SA passwords
- Once the weak SA account passwords have been identified, an attacker can run operating system commands using the built-in SQL stored procedure xp_cmdshell. The OS commands include the ability to add a new administrator to the SQL Server.
- Login as the newly created administrator on the SQL Server and extract local and domain password hashes
- Gain access to additional servers and workstations using the credentials, continuing to extract password hashes until a domain administrator account is located
- Extract and crack all domain user passwords from the domain controller
Sample of open source tools used:
SQLPing3, NetviewX, Metasploit Framework, Pwdump, Pass the Hash, Nmap, MBSA
How to mitigate it:
- Use your existing vulnerability scan process to proactively scan for blank or weak SA passwords on your internal network and DMZ. Once identified, notify the business owner and work with them to change the SA account to use a more complex password defined in your corporate standards.
- Set a restrictive account lockout for the ‘SA’ account on SQL Server 2005 and 2008 servers. By default in 2005 and 2008 the Windows password policy is extended to SQL logins with the exception of expiration. Preferably, disable the ‘SA’ account for mixed-mode instances and create separate administrative and application accounts with the necessary privileges.
- Monitor SQL server logon events to detect brute force activity on SQL Server logins.
- Set your internal HIDS to alert when there is a new local administrator added to a server on the network