Pwning WPA Enterprise with Hostapd on Kali Linux

Monday, August 31, 2015

Hey guys, welcome to another WiFi tutorial! Our last WiFi tutorial showed how to manually setup and configure an evil twin using a wireless router, but this time we'll be shifting gears into automating most of that process with hostapd. Hostapd is a powerful script which allows one to create an access point from an 802.11 card along with a RADIUS server. We'll be using hostapd-wpe, wpe for wireless pwnage edition.

In this tutorial, we'll cover how to properly setup an evil twin using hostapd, troubleshoot common issues and go over some ways you can protect against this attack vector. Before getting started, let's ensure we have what we need: VM or system running Linux, a wireless card (preferably Alfa cards) and some luck (see clip art above).


PEAP and EAP-TTLS are the most common EAP-types on wireless enterprise networks today. Both provide security through a TLS tunnel to ensure credentials can't be eavesdropped on like other EAP types (e.g., EAP-MD5, LEAP). Due to the TLS tunnel that's involved, an assessor would want to configure an access point with the same SSID as the access point s/he is impersonating (i.e., an evil twin). With similar configurations and a stronger signal one can hopefully lure clients to connect to their access point to obtain some credentials. Note: This won't work if clients on the network have been properly configured to validate certificates, but luckily, network administrators forget to do this more often than not.

Installing and Configuring Hostapd on Kali Linux

1. Let's download any dependancies that might be required using the code snippet below:

2. Now that we have the dependencies installed we need to download hostapd and hostapd-wpe. We also need to compile, apply the patch and create certificates for our access point. I made a small bash script to simplify this process:

3. Next plug your wireless card into your Kali system. I'm using an Alfa AWUS036NHA. Once this is done run the following command to see what interface your wireless device is, mine was wlan0:

If you're not seeing your device run the 'lsusb' command to ensure it is being detected by the operating system and troubleshoot from there. With the interface name in hand, we will make some modifications to Kali's network-manager. We will not allow network-manager to initialize the wireless card automatically because hostapd will need to initialize the device itself. Follow the code below to resolve this:

Optional: If you want to customize the certificates that will be presented go into the hostapd-wpe/certs directory and modify the files with the .cnf extension. Once you have modified the certificates use the bootstrap script once more to apply the changes.

4. Let's open up the configuration file in hostapd-2.2/hostapd/hostapd-wpe.conf and make some modifications. We will set the interface to the appropriate interface name, comment out the driver line, set the SSID, hw_mode, channel and wpa version. I've included the changes I made below:

Testing Our Installation

Time to start it up it! Go to the hostapd-2.2/hostapd directory and use the following syntax:

Awesome! We have our evil twin running. Let's test it out.

I also went ahead and customized the certificate to trick myself into authenticating since it looks soooo legit.
After I accepted the certification, we should see hostapd capture the credentials. Let's go check.
Awesome, we caught the creds! After you've captured the credentials use asleap to crack them. The following syntax can be used where the -C is the challenge, -R is the response and -W is your dictionary file:

That's it! You should now have a great understanding of how to use hostapd to create evil twin access points. Have fun!

Troubleshooting hostapd

Using Kali 2.0+?

G0tmi1k recently posted a great thread in Kali forums about troubleshooting Aircrack issues on Kali 2.0+. The biggest thing is to ensure one runs "airmon-ng check kill" prior to plugging in your card. For more information, check out the post here:

Hostapd having issues initializing the wireless card?

Ensure that the card is not initialized when plugged into the system. As I previously mentioned, change the network-manager settings to manual mode for the wireless card. Here's the syntax again:

Driver Nightmares?

If you're here you did not have the luck of the Irish. No worries! Neither did I. To paraphrase Joshua and Johnny, authors of Hacking Exposed Wireless Edition: "The tools you use are only as good as the hardware they are running on, but the best wireless card and chipset in the world are useless if the driver controlling it has no idea how to make it do what you want." I highly recommend that book, it's a great read.

In any case, I had many issues when I first started doing wireless testing. My wireless card was unreliable as it would constantly disconnect from the Kali VM. If you are using a virtual machine, I highly recommend making a snapshot prior to downloading and installing new drivers.

Alright, so let's get started. Find out what driver you need for your card. For example, I turned my card over and saw Atheros AR9271.
Bingo! I needed an Atheros driver so I went with ath9k_htc which supports several USB Atheros chipsets. I downloaded my drivers from following site, they have most of the wireless drivers you would need:

I went ahead and chose the compact-wireless driver. The website should eventually present you with a directory listing containing Linux Kernel versions. Use the following command to obtain your kernel version:

Next you'd want to click on the link with your kernel version and download the file ending in tar.gz. Once its done downloading use the following commands to install the new wireless drivers.

Preventing Evil Twin Attacks

Alright! We showed off how this attack is possible but let's see how to prevent it. First off, if your organization is using anything else but PEAP, EAP-TLS, or EAP-TTLS then switch over to those as soon as possible. PEAP, EAP-TLS, and EAP-TTLS ensure credentials can't be sniffed by transmitting them within an encrypted tunnel (hence the protocol name).

If your organization is already on PEAP, EAP-TLS, or EAP-TTLS then great! The next step would be to ensure clients are validating certificates. Clients should never be allowed to connect to an access point if certificate validation has failed. In order to make this happen an organization would have to have a certificate authority (CA) installed or issued by a known CA (this could be expensive). Additionally, do not prompt users to authorize new servers or certificate authorities.

Additional Reading

Hope you guys learned something new! If you have any questions or comments be sure to sound off in the comments below!

Preventing CredCrack, Mimikatz, Pass-the-Hash and more

Tuesday, August 18, 2015

Hey everyone! After releasing CredCrack last week I received many requests asking how someone should defend against it. This blog post will go over just that! Today we will be covering how to properly secure environments and prevent common attack vectors such as CredCrack/Mimikatz, pass-the-hash and more. I broke down the best practices into two major sections: Password and Account Security and Workstation Segmentation. Implement as many of the best practices listed below to ensure a more secure network.

Password and Account Security

Enforce Least User Access (LUA)

In 2008, BeyondTrust conducted research noting 92% of critical Microsoft software vulnerabilities would be prevented by the use of a limited user (no administrator rights).

Running an environment that implements the LUA philosophy would not only increase security but reduce the chances of users from installing or spreading malware. Keep in mind that if a limited user account is compromised, an attacker has one more layer to circumvent and security is all about layers (commonly referred to as defense in depth).

Remove rogue administrative accounts daily

Create a script that periodically checks administrative accounts for discrepancies. This could be done by having a list of known or valid administrative accounts and having a script periodically query administrators accounts.

Securing Administrative Accounts

Do not use domain administrator accounts to log into workstations. Domain administrator accounts should only be used to log into domain controllers and other sensitive systems. Additionally, ensure that a strict and complex password policy is implemented for all domain administrator accounts within the environment. See below for a list of password recommendations that should be enforced on all domain administrator accounts:
  • Must be at least fifteen characters in length. This would prevent Windows from storing an LM hash of the password.
  • Must include uppercase characters
  • Must include lowercase characters
  • Must include numbers
  • Must include non-alphanumeric characters
  • Must not contain the username/service name
  • Must not contain the system’s host name
  • Must not contain system details (i.e. make, model)
  • Must not be dictionary-based with character substitution (i.e. an “i” swapped for a “1”)
  • Must not contain character sequences (i.e. “qwerty”)
  • Must not be dictionary-based with common characters appended (i.e. “Password1”)
Wait! Let's not forget about local administrator accounts! Be sure to randomize local administrator account passwords upon every restart or disable the accounts if not needed.

Workstation Segmentation

Limiting communication and open ports

Attacks such as Pass-the-Hash and CredCrack need to interact with multiple systems within the environment. Limiting workstation to workstation communication would prevent passing hashes, CredCrack and pretty much every other attack with mass SMB logins.

First, it is recommend to disable or restrict access to NetBIOS and SMB ports (TCP: 139, 445). Today's corporate network environments do not have the need for workstations to communicate with one another for SMB and/or NetBIOS functionality. When necessary, create firewall exceptions to allow workstations to communicate outbound in order to reach any network shares on servers. While we're on the NetBIOS subject, let's also increase security by disabling NetBIOS over TCP/IP. This would prevent NetBIOS spoofing attacks, another popular attack vector.

Moving forward! Let's take a look at private VLANs. Private VLANs will give us the workstation-to-workstation segmentation we are looking for. Any workstation wanting to communicate with one would have to go out into the LAN and hit the router. This would allow strategically placed IPS/IDS systems to intercept and analyze any malicious traffic.

But wait, there's more!

Detecting Network Anomalies

Create a rule in IPS/IDS systems to detect anomalies such as mass SMB logins. It's not normal for a system to establish connections with 50 systems in a minute.

Disable Windows Digest

Implementing solely this registry setting won't do much, but it's still worthy of mentioning. Special thanks to reddit's /u/3dg3c4s3 for making this easy to find.

In system registry settings, "find security packages key in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa and delete the line wdigest from the list of packages". [Source]

For Environments on Windows 8+ and Server 2012

Research and consider using the Protected Users Group on Server 2012. Users added to this group would have the following settings:
  • NTLM would be forbidden. Account must use Kerberos or a third party SSP
  • Windows Digest (reversibly encrypted credentials) is not cached
  • Kerberos Ticket Granting Ticket (TGT) would have a shortened lifetime of 4 hours vs. 10 hours

Research and consider protecting the LSASS process:

Windows 8.1 introduces a new security feature that allows the user to mark LSASS as a protected process. Protected processes enforce greater access control and limit the available interactions from non-protected processes. When a process is protected only code signed by Microsoft may read its memory (even if the user has administrator or system rights). [Source]


The list of best practices mentioned above should do well in thwarting any of the aforementioned attacks if implemented in a network. Remember a network is not secure by how many products one purchases but the process. Be sure to create a network with defense in depth philosophy to reduce the chances of being compromised. That's all for now, if I missed anything feel free to sound off in the comment section below! Thank you!


Reddit /r/netsec and /r/sysadmin users (thank you for all the great comments!)

Domain Administrator in 17 seconds

Tuesday, August 11, 2015

Obtaining domain administrative privileges on a security assessment is a goal that many assessors seek. It is what fills us with excitement, as we know that the real fun is about to begin. After several assessments of crunching and spending time obtaining domain administrator privileges I decided that I wanted to expedite this process.

CredCrack was born.

CredCrack was developed in python and made to be quick and quiet. It exfiltrates credentials in memory and in the clear while highlighting domain administrator accounts for you!

How it works

CredCrack begins by setting up the stage. It will automatically start the apache service and deploy two files to your /var/www directory. One is named fun.ps1 and another named creds.php. Additionally, the assessor running the script is responsible for downloading Invoke-Mimikatz.ps1 and storing it in the same directory (/var/www).

After it is done setting up, CredCrack will validate the list of systems provided to ensure it can reach them and that they have port 445 open. It will remove systems that can't be reached and proceed to query systems for the list of domain administrators.

Once the list of domain administrators have been obtained, CredCrack will begin harvesting all systems for credentials. It will send an initial powershell command asking the remote system to connect back to the assessor's system, download and execute the contents of fun.ps1 in memory.

The fun.ps1 powershell script will execute mimikatz in memory and send back the credentials to the assessor's system in a POST request (which creds.php intercepts).

CredCrack will continue harvesting credentials for all systems provided then determine if any domain administrator credentials were obtained by matching each username with the list of domain administrators previously obtained. After that, CredCrack will output the results, gracefully clean up and quit.

Domain Administrator Credentials in 17 seconds

CredCrack has two main functionalities. CredCrack uses the provided local administrative user credentials to enumerate share privileges or harvest credentials across a network. to run. One reason to use the enumerate share functionality is to determine if the provided user has write or administrative access on a system. Refer to the syntax and example screenshot below for sample usage.

CredCrack's most valuable functionality is its ability to harvest credentials. Refer to the syntax and example screenshot below for sample usage.

Awesome! It's time to see CredCrack in action! The video below shows the fastest typer I know, Alton as he uses CredCrack and obtains domain administrator credentials in 17 seconds.


CredCrack was made to faciliate obtaining domain administrator credentials on an assessment. It has already helped me significantly on assessments and I hope it can help others as well. CredCrack does not have any dependencies other than Invoke-Mimikatz.ps1 if run on Kali Linux. For more information on CredCrack visit my Github page. For information on defending against CredCrack and similar attacks check out my other post.

Happy harvesting!