Network Design, Wireless Security, and Password Policies - Business Beware

Monday, October 15, 2012

Gary McCully


A while back I was on a wireless assessment in which I was able to compromise the client’s primary Windows Domain from their guest wireless network. My hope in writing this article is that organizations will take their network design, wireless security, and password policies a little more seriously.

Compromise “guest” Wireless Network

I started this assessment by using airodump-ng in order to identify all the SSIDs that belonged to the client. Using this tool I was able to identify both a corporate and guest wireless network. Both of these networks were using WPA2 with a pre-shared key (PSK). Although I also attacked the corporate wireless network during this assessment, for the purposes of this article I will focus on the steps I used to compromise the guest network.

The next step involved using airodump-ng in order to monitor network traffic destined for the guest wireless network. After only a minute or two of monitoring the wireless network, I was able to capture the 4-way authentication handshake between the Access Point and a device connecting to the wireless network. Once I had a valid handshake, I used aircrack-ng to start cracking the PSK. I gave aircrack-ng a list of dictionary words I wanted it to use for brute-forcing the PSK. After only a few minutes, aircrack-ng identified that a simple dictionary word was being used to limit access to the guest wireless network. Once I had the PSK, I used it to connect to the guest wireless network.


Once I was on the guest wireless network, I reviewed my network settings in order to determine what IP address range I was placed on. I port scanned this network in order to see if there were any other devices on this network that I could reach. The port scan results showed me that one of the devices on this range could be reached on ports 445 and 3389. Because port 3389 was open on this device, I made a Remote Desktop connection to the machine, and upon connecting to the server, I was presented with a Windows 2003 RDP login screen. The RDP login screen disclosed the fact that users could connect to the server using the client’s internal domain. Since this machine was a Windows 2003 server and it appeared to be able to authenticate against the client’s primary internal domain, I came to the conclusion that I had been dropped onto some sort of DMZ. I also believed that this server may have more access to the client’ internal network than I did. I made a note of the client’s domain name and disconnected from the RDP session.

Brute forcing

The next step in the compromise involved the use of Metasploit. I started Metasploit and configured it to use the smb_login auxiliary module. Then I configured this module to attempt to log in to the device I had previously discovered as part of the enumeration process. This involved setting the domain I wanted to authenticate against (which I already knew from the enumeration phase) as well as giving it a list of usernames and passwords to use as part of the authentication attempts. For the username, I gave it a list of common dictionary words, and for the password, I configured it to use a password that was identical to the username. After the brute force had finished running, I had discovered a valid domain account which had administrator level access to this server.


The next step involved using the psexec Metasploit module in order to log in to the server. In order to do this, I used the domain account I had discovered during the previous phase. I then chose a reverse Meterpreter shell as my payload of choice. Upon running the exploit, I was greeted by a Meterpreter shell. I then reviewed the server’s network address information, and verified the fact that the server had access to the client’s internal network (including their Domain Controller). Next, I dumped the hashes on this server, backgrounded the Meterpreter shell, and created a route to forward traffic through the Meterpreter session onto the internal network.


Finally, I used smb_login to attempt to log in to other servers on the internal network using the same local administrator password I had obtained from the compromised server that was on the guest network. To my delight, the client was using the same local administrator password on all the servers on their internal network. I used psexec to gain a reverse Meterpreter shell on one of these servers. Then I loaded Incognito and impersonated a Domain Administrator’s Kerberos token. With the impersonated token, I created my own Domain Administrator account. At this point I had full Domain Admin access to the client’s internal network.


A significant number of different vulnerabilities were linked together in order to compromise the client’s internal network. I will not take time to address all the problems that led to the compromise of the client’s network; however, some of the most extreme vulnerabilities must be highlighted:

  • Improper Network Segmentation – During this assessment, I should not have been able to access the client’s internal network through a server I had compromised on the “guest” wireless network. These networks should be fully segmented from each other, and the compromise of a machine on the “guest” network should not result in access to the internal corporate network.
  • Weak Password Policy – No account should have a username that is identical to the password. Additionally, weak passwords such as “Password”, “Password1”, the company’s name followed by the number 1, etc., should not be used. In reality, the age of the password should be coming to an end, and organizations should start encouraging their users to start using passphrases. For example, instead of choosing a word and adding numbers and special characters to it, it is better to choose a small phrase and add a few letters and numbers to it. Passphrases like “i l0v3 2_Go J0gG1n9!” are easy to remember and would be very difficult for an attacker to crack.
  • Local Admin Passwords Shared on Multiple Devices Across the Network – When multiple devices across the network share the same local admin password, if the attacker gains access to one of the servers, that attacker would have access to all the devices that share the same password. Each device must have its own unique password.

The client made basic, easily avoidable errors in regard to their wireless security. However, the criticality of these errors was greatly increased by failures in network design and password policies. What should have been a simple (troubling, but lower risk) compromise of a guest network turned into a complete compromise of the internal corporate domain.

Possibly Related Articles:
Information Security
Passwords Wireless Network Security Policies and Procedures
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.