Performing an Evil Twin Attack with a Router

Thursday, February 5, 2015

An evil twin is a common attack vector in any environment where wireless access is available. The attack consists of an attacker spoofing an access point to look as legitimate as its counterpart in attempts to harvest credentials.

With that being said let's take a look at how to set up an evil twin access point in an WPA2 Enterprise environment.

What you'll need:

Please remember, this is solely for educational purposes. 
The techniques mentioned below are not to be used for malicious purposes outside of a controlled research environment.

Why do we need a router?

We need a router because we are using the old school method! Scripts like hostapd-wpe or lootbooty can configure and perform the evil twin attack and much more with the presses of a few buttons. However, if you'd like to learn the fundamentals this is a great tutorial. I'm actually making this tutorial because I didn't find any on the web specifically with a physical router involved. I had to resort to this solution recently at a client site due to some unforeseen complications so I definitely recommend reading and trying out this tutorial. It could come in handy!

Setting up the Evil Twin

Since we're going to be intercepting enterprise communications we must first set up a radius server. We will be using freeradius-wpe in this example. Once we set up our radius server on kali then we will configure our access point/router appropriately and should be all set!
  1. Download freeradius-wpe to your Kali Linux virtual machine (vm). I will be using free radius 2.1.12 in this example.
  2. Download the freeradius-wpe patch.
  3. Untar the download:
  4. Change directory into the freeradius-server folder and apply the patch: 
  5. Configure, make and install:
  6. Make the certificates:

Great! We're now done with the radius server set up. To test it out run the radiusd -v command. Regardless of what version you installed, the output should look similar to the one below.

Alright. Now that we can confirm that our radius server installed correctly, let's make some changes to the configuration file.
  1. Let's change directories to the location of the configuration files: cd /usr/local/etc/raddb/
  2. Open radiusd.conf with your favorite editor and ensure that eth0 is uncommented. I've included a snippet of what this setting looks like below in order to facilitate finding it. This should be around line 290 of the configuration file.
  3. Next we're going to open clients.conf and add a new client with the address of our router and a secret phase (this can be anything). Below is the client I added to the configuration file.
  4. Create a log file named freeradius-server-wpe.log under the /usr/local/var/log/radius/ directory. This log file will store any credentials we capture during the test.
  5. Alright, now for the fun part. Let's configure our router to use WPA2 Enterprise and use the IP address of our Kali VM as the radius server. Enter the secret previously saved within the client.config file. I've included a screenshot of how my router settings looked like below. Note that the router's SSID is set to "eviltwin_test", attackers will usually set this to whatever SSID they are trying to spoof.

We are all set! Let's start up the radius server with the radiusd -X command and let's test it out. I will be using my phone to authenticate to the evil twin....annnnnddd success!! It worked!! Here are some screenshots on what the radius server should be outputting as well as the logfile containing the username and password I just entered.

A quick note. Not all clients who authenticate to the radius server will succeed. Additionally, not all passwords will be in clear-text, in fact most of the time hashes are the ones obtained.

Hope you guys learned something new. Remember this is an old school technique that can be used to learn or as a Plan B. Before you go check out how to prevent this from happening in your environment with some mitigation tips below.

Go Mitigation!

The example above depicts how to successfully spoof an access point and capture user credentials. An attacker can use these credentials to infiltrate a network and possibly obtain sensitive information. This is bad news for any environment. Let's explore some ways to protect against this attack:
  • Ensure your environment is using a secure protocol such as EAP-TLS
  • Implement client side certificates for authentication and validate those certificates
  • Do not self-sign certificates
  • Implement a Security Awareness program for employees

Additional Reading

For more detailed information on evil twin attacks and recommendations check out the following:

Installing MinGW (gcc, g++) on Kali Linux to Compile Windows Code

Wednesday, March 5, 2014

It is possible to compile windows code natively in Backtrack and Kali using MinGW compiler and Wine. While MinGW comes already installed and configured for users in Backtrack, it does not in Kali.

Let's go over how to install and configure MinGW for Kali and how to use it to compile windows code, but first some quick definitions.

What is Wine?

Wine allows windows applications to be run on several platforms such as Linux, Mac OS X and more.

What is MinGW?

MinGW is a collection of windows development tools including compilers such as GCC and G++. Using both MiniGW and Wine it is possible to compile windows code thus creating a portable executable (pe) which can be later run with wine.

Installing MinGW on Kali Linux

As previously mentioned, MinGW does not come installed on Kali by default. Thus one does not have access to important tools and compilers such as gcc. Let's install and configure it.

  1. Download the MinGW installer from their sourceforge.
  2. Run the installer (mingw-get-setup.exe) with wine.

  3. Select the Install with GUI option.
  4. The MinGW installation manager should now be open. Select mingw32-base.

  5. Select Installation > Update Catalogue on the top left hand corner.

  6. Some missing DLLs will need to be downloaded, download them here
  7. Unzip them and move them to the wine drive_c/windows folder.

Excellent, we now have Mingw installed! You can confirm this by visiting the /root/.wine/drive_c/MinGW directory. You should also have gcc installed under /root/.wine/drive_c/MinGW/bin/gcc.exe.

Compiling Windows Code in Kali and Backtrack

With MinGW installed all we have to do now is use gcc to compile our c code. Below is an example of usage. The example below assumes the user is inside the /root/.wine/drive_c/MinGW/bin directory.

There we have it! Go Compile!

Buffer Overflow: Smashing the Stack Tutorial

Tuesday, October 22, 2013

Buffer Overflows or stack smashing are common attack vectors. There are numerous tutorials online on how to perform buffer overflows and the theories behind them, but in this example we'll dive in a little deeper.

What you'll need:

Please remember, this is solely for educational purposes. 
The techniques mentioned below are not to be used for malicious purposes outside of a controlled research environment.


A stack overflow is accomplished when one overwrites the space allocated for the stack. Let's take a look at simple example. Below we have a program which takes a five digit zip code from a user and places it into an array of five elements. Can  you see a problem with this program?

If you were thinking that there was no bound checking you are correct! This program does not validate user input thus allowing a malicious user to input a zip code containing a thousand characters if s/he wishes. Let's check to see how the stack looks like during the execution of this program. The image below depicts the Stack Example.

For simplicity purposes I have divided the stack into three blocks. The first block will contain the zip code array, the second block will contain the saved frame pointer (ESP), and lastly the return address (EIP). Once the user inputs his/her zip code the character array will be populated as shown below.

Excellent. The program seems to be working thus far. The zip code, 89101, was stored within the zip code array just fine. However, what happens when a user decides to send a thousand characters? Let's take a look.


 Oops! The program has crashed. This happens because the program had no bound checking. If the program were to have implemented input validation and used the strlcpy instead of strcpy function then this could have been avoided.

Now you may be asking yourself, how exactly can someone exploit this? Well, if the user wants to inflict some damage then s/he must find enough space for their payload and make the application point to the payload at the time of the crash. Let's go through this in detail.


Before we get started, be sure to go through the bullet points below to make sure you're ready to go:

  • Ensure that both of your virtual machine's (windows and kali/backtrack) network settings are set to internal/host only.
  • Install Free Float FTP and Immunity Debugger onto your Windows OS.
Great you're locked and loaded. In order to see and investigate the crash we need to attach the FTP server to a debugger, Immunity Debugger.

Open Free Float FTP and Immunity Debugger. Once inside Immunity Debugger go ahead and attach the FTP executable.

Next, click on the play button (F9) in the toolbar. We are now running the FTP server successfully under Immunity.  Check out the application's register values on the top right column within Immunity. They should look like the ones depicted below.

Now, let's move on to the fun stuff. In your Kali/Backtrack machine let's make a simple proof of concept code to see the crash happen. In this application, the buffer overflow vulnerability is trigged when a user submits 1000 characters to the application. Every application is different and requires fuzzing in order to determine the point of the crash.

Our proof of concept script below submits a thousand letter A's to the application using the FTP MKD command.

If you do not understand what this program is doing then I highly recommend you visit the python documentation.

After running the proof of concept script we can see that the FTP server registers (specifically ESP, EDI and EIP) within Immunity debugger have changed and are now populated with letter A's (EIP is populated with 41414141 which is the hex value for letter A). This means we have successfully trigged the buffer overflow vulnerability!

Now that we have overwritten EIP we must find where exactly EIP was overwritten. To do this we will use metasploit's pattern create and pattern offset scripts. The pattern create script will create a unique string for a given length. We will create a string consisting of 1000 characters and place that into our program's buffer variable.

Be sure to restart the debugger and FTP application before running the proof of concept script again. Once executed the registers will now be overwritten with the unique pattern. EIP, ESP and EDI should be overwritten. Copy the EIP value (should be 69413269) and use metasploit's pattern offset to figure out exactly where the location of EIP is at the time of the crash.

Great, we can see that the offset or location for EIP occurs at the 247th byte. Repeat this process for the other registers to obtain their respective offsets.

We now have the locations of EIP, ESP and EDI. In this example we will be placing our shellcode at the beginning of the ESP register, but first we must find an instruction to jump to our shellcode. What does this mean? Let's break that concept down.

An application is constantly performing actions and going through instructions. Our goal is to control the execution of the application. Once we control the execution then we would be allowed to insert our own instructions.

The EIP register keeps track of the address for the next instruction. In other words, it controls program execution. What we must now do is find an instruction within that says go to ESP or jmp esp which would make the application go to our shellcode.

Within Immunity click on View > Executable Modules and select user32.dll. We should now have User32.dll loaded within Immunity. Right click within the module and search for a command containing JMP ESP.

Great, we now have the JMP ESP instruction located at 768C4E5B. Now within our proof of concept we will place this value in little endian after the EIP offset followed by our shellcode after the ESP offset. I used metasploit to create shellcode to execute a windows calculator. 

Be sure to also include some NOPs (\x90) for shellcode padding and then restart the FTP application without Immunity debugger and launch the proof of concept code. There we have it! 

We have successfully exploited the buffer overflow vulnerability for Free Float FTP and hopefully obtained a better understanding of buffer overflows. Check out the full proof of concept code here.

Go Further! 

I highly encourage anyone to dive deeper into this subject matter. This example was very simple but there is much more to be learned. Go check out some of the sites mentioned below for a better understanding.

Special Thanks to b33f @ Fuzzy Security. Be sure to check out his in depth exploit development tutorial at fuzzy security.