7-7-2014 Evil Twin Attack Explanation

Eric Goldman2.0 Search

Web Development, System Administration, & Security

Home Web Development System Administration Security End-User Non-Technical Contact

Evil Twin Attack Explanation

Security - Exploits and Attacks
Thursday, 14 May 2009 12:15
Keyword Cloud

privacy forensics mobile access

Note, this report is for educational purposes only. The experiment was carried out in a secured lab setting. point aircrack-ng encase VMware iPod
sleuthkit evil twin wireless Joomla
You should NOT try this at home. If you perform the Evil Twin attack in public, you are almost certainly
identity theft red flags rule DWDM
committing a crime (e.g. computer trespass) in your state/province/country. I will not be held responsible for ethernet web design leadership forms web
your usage of information. Use your knowledge for good, not evil. security

This report is also available as a PDF, which includes the full Appendix and all content, which may not be
shown here. Please note, some external documents such as original packet captures will not be provided. If
you just want to see the attack and not read the details, then check out the presentation version, complete Latest Articles
with example videos. Customize the Frontpage / Home Page
Template in Joomla 1.5
Primer on Character Encoding Settings
with HTML/PHP
Vulnerability Report: Information
Exposure in Oracle's iRecruitment
How to make drop-down boxes ( select
elements) with JHTML.
Input Sanitization using JRequst

Network Topology

System Profiles

System: Victim

Purpose Victim Machine, emulate real user falling

for attack
Hardware IBM t42 Laptop

Operating System Windows XP SP 3 (Build: 2600)

http://www.ericgoldman.name/security/8-exploits-and-attacks/21-evil-twin-attack-explanation 1/7
7-7-2014 Evil Twin Attack Explanation
OS Modifications Nothing special, real client machine used
in daily computing; no changes to
wireless networking, used Windows
Wireless Management
Wireless Hardware Built-in Internal Laptop Card
(Drivers) Atheros chipset (Atheros athw.sys version
7.4.2.105 )
Wireless Card MAC 00:0E:9B:6E:28:7D

IP Address Settings Provided by AP

On Fake AP: 10.0.0.100
On Real AP: 192.168.1.100

System: Monitor/Capture

Purpose Not involved in attack, used to capture

wireless packets
Hardware IBM t42 Laptop

Operating System Backtrack 3 Live CD

OS Modifications No modifications

Wireless Card (Drivers) Built-in Internal Laptop Card

Atheros chipset (madwifi-ng)
Wireless Card MAC 00:0E:9B:6E:28:9A

IP Address Settings Only used in monitor mode; does not

require setting IP Address

System: Real AP

Purpose A Real AP that the user would be

connecting to normally.
Hardware Linksys WRT54G

Operating System Official Linksys Firmware

(Version: 1.02.5)
OS Modifications No additions or changes to OS/Firmware

Wireless Card (Drivers) Built-in wireless interface of router/AP

(N/A)
Wireless Card MAC 00:0E:9B:6E:28:7D
(Wireless AP Interface)
IP Address Settings IP Provided by RIT DHCP; Provides
DHCP to Clients in 192.168.1.0/24 subnet

System: Fake AP

Purpose A laptop masquerading as a legitimate AP

for man in the middle
Hardware IBM t42 Laptop

Operating System Backtrack 4 Beta Live CD

OS Modifications Updated aircrack-ng suite via svn

(Version 1.0-rc3 Revision/Build 1508)
Wireless Card (Drivers) Built-in Internal Laptop Card
Atheros chipset (madwifi-ng)
Wireless Card MAC 00:0E:9B:BF:AA:B2 (Wireless AP
Interface, when setup as AP,
automatically set)
IP Address Settings IP Provided by RIT DHCP; Provides
DHCP to Clients in 10.0.0.0/24 subnet

Software Used
Victim
The Victim Laptop is running a standard Windows XP setup in terms of wireless. Wireless is managed by
windows and not by third party program.

Monitor/Capture
On the monitor/capture laptop, the Backtrack 3 Final Live CD was used. Because this machine was only being
used to monitor, nothing was added or changed. In order to capture wireless traffic, airodump-ng (version:

http://www.ericgoldman.name/security/8-exploits-and-attacks/21-evil-twin-attack-explanation 2/7
7-7-2014 Evil Twin Attack Explanation
1.0 rc1 r1083) was used. To put the system into monitor mode airmon-ng (version: 1.0 rc1) was used. Both of
these applications are included by default in Backtrack 3 and were not modified in any way for this project.

Fake AP
In order to run the Fake AP tools from the aircrack-ng (http://aircrack-ng.org) suite were used. The specific
tools used airmon-ng (version: 1.0-rc3) and airbase-ng (version: 1.0 rc2 r1385). Some built in system
commands were also used such as modprobe, which is used to load kernel modules
(http://linux.die.net/man/8/modprobe). In addition, in order to provide routing for the clients once they
connected to the Fake AP, dhcpd (version: 3.1.1) and iptables (version: 1.4.0) were used.

Real AP
Nothing special was used on the Real AP, only the Linksys web management interface.

Scenario Overview
In this scenario, we emulate an Evil Twin attack. An Evil Twin attack is where you create either a physical AP
or soft AP that mimics the AP which a user will connect to. The idea is that either through user error or
application design, you will trick a user into connecting to your fake AP instead of the original AP. When the
user connects to your Evil Twin, you will have the ability to commit man-in-the-middle (MitM) attacks.

The attack starts with the Victim workstation connected to the real AP. Either through knowledge or
reconnaissance you find out the relevant information about the real AP. Usually, the SSID is sufficient, but
you may also want to imitate the user’s channel as well. After you have obtained this data on your attacker
workstation, you start airbase-ng using the setting you have acquired from the Real AP. It is possible to set
airbase-ng to respond to any probe request, however, we targeted our attack to a specific SSID in order not to
attack any innocent workstations that were within transmission range. Once you have started airbase-ng, you
must setup the client routing, which is described in detail below. The Fake AP will begin to constantly send
out deauthentication packets to the victims pretending to be the Real AP. In addition, it will also begin to
send out Probe Responses for the Real AP’s SSID, but with its own MAC. These packets are sent in order to
force the victim to disconnect from the Real AP and then connect to the Fake AP. After a few seconds, the
Victim will deautheticate from the Real AP and then authenticate with the Fake AP. If our case, the Victim
receives it IP from the AP’s DHCP server. The client may try to request its current IP from the new AP. In our
case, the IPs available on the Fake AP are in a different subnet. Therefore, the client temporarily loses higher
level connectivity, and takes on an automatic private IP; however, eventually it will get a new DHCP address
from the Fake AP. To the user on the Victim machine, it simply seems that they have lost their connection
temporarily; when they can continue browsing the web after a few seconds, they do not notice anything
different about their connection. As a result, the attacker is now free to commit MitM attacks on the Victim.

In our scenario, we have also set up a third workstation to capture traffic. This machine is not part of the
network, and only captures traffic. The process for setting up the monitoring machine is also described below.

Running the Scenario

Setting up Monitoring
In order to capture the events of the attack, a third laptop was used (Monitor/Capture) and the aircrack suite
was used to capture traffic. The traffic was saved as .cap files which can be opened in protocol analyzers /
packet capture software such as Wireshark.

In order to setup monitoring do the following on the Monitor/Capture machine:

1. Boot Live CD

2. Login as user “root” with password “toor”

3. Run iwconfig to find out the name of your wireless card on the system, this is usually something like wlan0 or
wifi0, though some wireless card with just be assigned as eth1. Note, the number at the end is dependent
upon the number of devices on a system, and the order they loaded. On the system used in this lab, the
wireless adapter is “wifi0”

4. Use airmon-ng to activate monitor mode:

airmon-ng start wifi0

5. This will create a new virtual (VAP) interface and place it in monitor mode. The name will depend upon the
drivers, but it will be something similar to ath0. In this case ath2, was created. Every time you run airmon-ng
on a real interface, a new virtual interface will be created unless you deleted the previous one. If you want to
destroy a virtual interface you would type something like:

airmon-ng stop ath2

Note, you should not run the stop command against wifi0, but only the virtual interfaces. Having extra,
unused interfaces will not necessarily cause a problem, but they are not needed and will result in printing
useless or unnecessary information to the screen when you run some commands.

6. Once you have a virtual interface in monitor mode, you can start capturing traffic. The general form is:
airodump-ng [interface name] –c [channel #] --bssid [MAC Address of AP] -w [filename]

The interface name is required, and should be the name of your monitoring interface, in our case ath2. The –c
option allows you to specific the specific channel to listen on, this helps reduce the number of extraneous
packet collected. The --bssid option allow you to filter for a specific AP, since we are only interested in
connections to either the Real AP or Fake AP this also helps reduce the number of extraneous packet. The –w

http://www.ericgoldman.name/security/8-exploits-and-attacks/21-evil-twin-attack-explanation 3/7
7-7-2014 Evil Twin Attack Explanation
option is used to save the dump to a file and the value is used as the prefix for the output files.

For our case, we ran the following:

To Capture against the Real AP:

airmon-ng ath2 -c - 2 --bssid 00:0E:9B:6E:28:7D -w RealAPCapture

To Capture against the Fake AP:

airmon-ng ath2 -c - 2 --bssid 00:0E:9B:BF:AA:B2 -w FakeAPCapture

7. The output of running the capture command will make two files, a *.cap file and a *.txt file. The *.cap file can
be opened by Wireshark/tcpdump for analysis and the *.txt file has a summary of the capture in human
readable format. In this demo, the APs were not active at the same time in order to make it more clear what
was happening in the captures.

Running the Fake AP

The following commands are run on the Fake AP laptop. There are two main stages, the first is updating
software and configuring the services required for the attack, and then running the actual attack.

Setting up the Fake AP Basics

1. Boot Live CD

2. Login as user “root” with password “toor”

3. First, bring up the wired Ethernet interface (eth0). This is necessary in order to get the software updates
needed to run the attack successfully. To bring up the interface and have DHCP assign an IP address run the
following commands:

ifconfig eth0 up
dhclient
An IP address will be provided by the public DHCP server that connects us to the Internet.

4. The next step is to update the aircrack-ng suite since the included version on Backtrack 4. We accomplish this
using subversion and make files. An understanding of subversion and compiling is not required, simply run
the following commands to download, compile, and install:
svn co http://trac.aircrack-ng.org/svn/trunk aircrack-ng

cd aircrack-ng/

make && make install

This will download and compile the latest version of aircrack-ng on your system.

5. The next step is to properly configure the DHCP server (dhcpd). You should edit the following configuration
file:
/etc/dhcp3/dhcpd.conf

Clear any settings currently in the file, and enter the following:

option domain-name-servers 10.0.0.1;

default-lease-time 60;

max-lease-time 72;

ddns-update-style none;

authoritative;

log-facility local7;

subnet 10.0.0.0 netmask 255.255.255.0 {

range 10.0.0.100 10.0.0.254;

option routers 10.0.0.1;

option domain-name-servers 129.21.17.3, 129.21.18.4;

}
These settings will setup the necessary DHCP settings. A subnet is created on the 10.0.0.0/24 subnet. The
other settings will later correspond to the iptables settings used for NAT translation. In some instances it may
be necessary to change the domain-name-servers value on the first line to one of your external, provided DNS
name servers, only change this if you experience problems.

Running the Fake AP

With the above software updates and settings, we are now ready to setup the Fake AP. There are two separate
phases, starting the Fake AP program and then setting up client handling through the iptables routing and
running DHCP. You can run the Fake AP steps and then the Client steps all in one window, but it is easier to
use two or more windows.

http://www.ericgoldman.name/security/8-exploits-and-attacks/21-evil-twin-attack-explanation 4/7
7-7-2014 Evil Twin Attack Explanation
Start the Fake AP
1. Start up a monitoring interface to run the Fake AP ontop of, the explanation of these steps it already outlined
above, so only the commands will be shown here:
iwconfig
airmon-ng start wifi0
In this case, a virtual interface ath0 was created.

2. Next, we run the modprobe command to load the tun (tunneling) module
modprobe tun
This is necessary for routing later. For more information about tun module see:
http://www.kernel.org/pub/linux/kernel/people/marcelo/linux-2.4/Documentation/networking/tuntap.txt

3. Now, we used airbase-ng, part of the aircrack-ng suite to start a fake AP:
airbase-ng -e " Group5Test " -c 2 -v ath0
Since the real AP we are attacking is called “Group5Test”, we set the –e field, which is for ESSID to the same.
The –c option is for channel, and thus we choose channel 2 since our real AP also used this; in most cases the
user or the software will connect even if you use a different channel. Last we specify the –v option which is for
the interface, in this case ath0. There are other commands that can be used to force deauthentication attacks
or WEP stealing, they were not used in this attack in order to protect innocent workstations not part of the
scenario environment. This command will provide output; if you are running as a script you should redirect
output. We chose to run the Fake AP commands in their own window so we could observe the output.

Start Services
Services should be started after the Fake AP is up, the following can be run as script, all commands should be
run each time. We chose to run these commands through a script, in a separate window from the commands
in the previous section.

1. Create the tunneling interface and configure.

ifconfig at0 up

ifconfig at0 10.0.0.1 netmask 255.255.255.0

ifconfig at0 mtu 1400

You may require different settings depending upon your hardware and DHCP settings. The at0 interface is
created by airbase-ng when it is run, using airtun-ng (which is also part of the aircrack-ng suite). This is why
these commands must be run after the Fake AP is started.

2. Create the default route using the built-in route command:

route add -net 10.0.0.0 netmask 255.255.255.0 gw 10.0.0.1

Again, your settings should match those specified in your dhcpd.conf file above.

3. Next, we configure iptables to perform network translation using NAT in order to connect our clients to the
Internet like a router would:
iptables --flush

iptables --table nat --flush

iptables --delete-chain

iptables --table nat --delete-chain

These commands remove any old settings that may have been set.
iptables -P FORWARD ACCEPT

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

The above statements set up network translation and forwarding, eth0 is selected because it has access to the
Internet/target network.

4. Next, we configure DHCP.

echo > '/var/lib/dhcp3/dhcpd.leases'

dhcpd3 -d -f -cf /etc/dhcp3/dhcpd.conf at0 &

The first command will empty out any old leases that may be present from a previous run. The second
command is used to start the DHCP server using our configuration file specified earlier and through the
tunneling interface created when the Fake AP was started. You may want to redirect the output of dhcpd3 to a
file or /dev/null, the DHCP exchanges are configured to be logged in our dhcpd.conf configuration file above.

5. This last step may not be necessary, but it is used to ensure that the system allows IP packet forwarding.
echo "1" > /proc/sys/net/ipv4/ip_forward
Get more details about this command at: http://linuxgazette.net/issue77/lechnyr.html

Once these commands have been setup and run, any user will be able to connect to your Fake AP as if it were
a Real AP. They will have access to any services you provide, and you can perform many different attacks.
This particular setup could also be used to create a non-malignant Fake AP if desired.

Results
The Victim laptop first connected to the valid AP. After the Fake AP was started, the Victim was

http://www.ericgoldman.name/security/8-exploits-and-attacks/21-evil-twin-attack-explanation 5/7
7-7-2014 Evil Twin Attack Explanation
deauthenticated from the Real AP and then authenticated with the Fake AP. No Specific DoS attack was
launched against the Real AP, the attack only relies on communication between the client and the Fake AP.

We will now show some relevant packet capture from the attack. This will help demonstrate how the attack
works, the full details of the attack can be found in the Appendix I.

Video Capture
We used screencasting software on all 3 laptops to show the attack. Please visit the following YouTube link if
you would like to watch the video:

http://www.youtube.com/view_play_list?p=41518E3B27EE602B

Remember to enable HD to better read the onscreen text.

Packet Captures
Here is a brief summary of the packets below: First we see the DHCP Request & ACK from the real AP. We
then see the Fake AP come up and begin to send deauthentication packets, though it looks like they are
coming from the Real AP. The Real AP continues to send Probe Responses. The Fake AP will continue to send
the falsified deauthentication packets and then begins to send its own Probe Responses to the client.
Eventually the Victim and Fake AP authenticate and then associate with each other. You can then see that the
Victim checks to see if it can have its current IP address, then goes to automatic private address, then
eventually receives DHCP from the Fake AP. You should also note, that as long as the Fake AP is running, it
will continue to send Probe Responses and the falsified Deauthentication packets in an attempt to keep the
client from going back to the Real AP. Please see Appendix I for the full packet details.

[[[Please see the PDF version for this part of the report]]]

Thoughts on the exploit and defense

On its own, the Evil Twin attack is not very interesting or necessarily dangerous. However, once the attack
has been committed, it opens the door for many more attacks which can cause damage or help with
reconnaissance and further network penetration. The Evil Twin attack however is very important. It
demonstrates the weaknesses with the design of 802.11 management that allow for an attacker to easily
manipulate network management features. Looking at such attacks can help designers of future versions to
develop more secure protocols and is important for current wireless network administrators to understand
the threats to their network.

The Evil Twin attack is fairly easy to perpetrate. The software is freely available and a very large number of
wireless chipsets are supported. As a result, any script kiddie can learn how to use the tools then deploy a
Fake AP in public. Users who already trust public Wi-Fi are not likely knowledgeable to know they were ever
attacked. As a result, their connections will be hijacked and any number of MitM attacks may be used.

The Evil Twin attack can be detected and its effects limited to some extent (Schiffman, 2007). Protective
issues include installing a wireless intrusion prevention system (WIPS); most commodity WIPS can prevent
against these attack by default. Other protective measures may include installing extra security layers such as
802.1x. In addition, network administrators should monitor traffic and perform site surveys in order to detect
Evil Twins and other Rogue APs.

References

Hackers come up with new methods to hack Wi-Fi networks. (2008, March 21). Retrieved April 6, 2009,
from Internet Security: http://www.internet-security.ca/internet-security-news-010/hackers-coming-up-
with-new-ways-to-hack-wi-fi-networks.html

Mateti, P. (2005). Hacking Techniques in Wireless Networks. Retrieved April 6, 2009, from Wright State
University: http://www.cs.wright.edu/~pmateti/InternetSecurity/Lectures/WirelessHacks/Mateti-
WirelessHacks.htm#_Toc77524669

Phifer, L. (n.d.). Anatomy of a Wireless "Evil Twin" Attack (Part 1). Retrieved April 9, 2009, from Watch
Guard: http://www.watchguard.com/infocenter/editorial/27061.asp

Schiffman, N. (2007, October 4). How 'evil twins' and multipots seek to bypass enterprise Wi-Fi defenses.
Retrieved April 10, 2009, from Tech Target:
http://searchsecurity.techtarget.com/tip/0,289483,sid14_gci1274396,00.html

--::--

http://www.ericgoldman.name/security/8-exploits-and-attacks/21-evil-twin-attack-explanation 6/7
7-7-2014 Evil Twin Attack Explanation
Tags evil twin :: man-in-the-middle :: access point :: wireless :: aircrack-ng

Add this page to your favorite Social Bookmarking websites

Comments
Click Here to Show/Hide Add Comment Form Please login to post comments or replies.

© 2009 Eric Goldman. All rights reserved. Credits: Web Design Hero, NodeThirtyThree Design, Joomla Professional Solutions

http://www.ericgoldman.name/security/8-exploits-and-attacks/21-evil-twin-attack-explanation 7/7