mdk3
mdk3 Description
MDK is a proof-of-concept tool to exploit common IEEE 802.11 protocol weaknesses.
This version of MDK3 has a new feature that sends directed probe requests with invalid SSID characters to an AP. The hope is that if enough probes are sent, the AP will lock up and reboot.
MDK3 is a tool that "injects" data into wireless networks. "Injection" is the possibility to send self-made data through the air without being connected or associated to any network or station. MDK3 is used to send valid and invalid packets, which belong to the wireless management and not to regular data connections. This is only possible with this Injection technique. Sadly, this is something, WiFi equipment has NOT been built for in the first place! To enable the injection feature on your wireless card, you possibly need modified drivers. A lot of work has already been done by several hackers (including me) to make these modified drivers available for a lot of hardware. Furthermore, the new wireless subsystem mac80211 in the Linux kernel supports Injection out of the box for many drivers and cards.
Homepage: https://github.com/charlesxsh/mdk3-master
Author: ASPj of k2wrlz
License: GPLv2
mdk3 Help
MDK USAGE:
mdk3 <interface> <test_mode> [test_options]
Try mdk3 --fullhelp for all test options
Try mdk3 --help <test_mode> for info about one test only
TEST MODES:
b - Beacon Flood Mode
Sends beacon frames to show fake APs at clients.
This can sometimes crash network scanners and even drivers!
a - Authentication DoS mode
Sends authentication frames to all APs found in range.
Too much clients freeze or reset some APs.
p - Basic probing and ESSID Bruteforce mode
Probes AP and check for answer, useful for checking if SSID has
been correctly decloaked or if AP is in your adaptors sending range
SSID Bruteforcing is also possible with this test mode.
d - Deauthentication / Disassociation Amok Mode
Kicks everybody found from AP
m - Michael shutdown exploitation (TKIP)
Cancels all traffic continuously
x - 802.1X tests
w - WIDS/WIPS Confusion
Confuse/Abuse Intrusion Detection and Prevention Systems
f - MAC filter bruteforce mode
This test uses a list of known client MAC Adresses and tries to
authenticate them to the given AP while dynamically changing
its response timeout for best performance. It currently works only
on APs who deny an open authentication request properly
g - WPA Downgrade test
deauthenticates Stations and APs sending WPA encrypted packets.
With this test you can check if the sysadmin will try setting his
network to WEP or disable encryption.
b - Beacon Flood Mode
Sends beacon frames to show fake APs at clients.
This can sometimes crash network scanners and even drivers!
OPTIONS:
-n <ssid>
Use SSID <ssid> instead of randomly generated ones
-f <filename>
Read SSIDs from file
-v <filename>
Read MACs and SSIDs from file. See example file!
-d
Show station as Ad-Hoc
-w
Set WEP bit (Generates encrypted networks)
-g
Show station as 54 Mbit
-t
Show station using WPA TKIP encryption
-a
Show station using WPA AES encryption
-m
Use valid accesspoint MAC from OUI database
-h
Hop to channel where AP is spoofed
This makes the test more effective against some devices/drivers
But it reduces packet rate due to channel hopping.
-c <chan>
Fake an AP on channel <chan>. If you want your card to hop on
this channel, you have to set -h option, too!
-s <pps>
Set speed in packets per second (Default: 50)
a - Authentication DoS mode
Sends authentication frames to all APs found in range.
Too much clients freeze or reset almost every AP.
OPTIONS:
-a <ap_mac>
Only test the specified AP
-m
Use valid client MAC from OUI database
-c
Do NOT check for test being successful
-i <ap_mac>
Perform intelligent test on AP (-a and -c will be ignored)
This test connects clients to the AP and reinjects sniffed data to keep them alive
-s <pps>
Set speed in packets per second (Default: unlimited)
p - Basic probing and ESSID Bruteforce mode
Probes AP and check for answer, useful for checking if SSID has
been correctly decloaked or if AP is in your adaptors sending range
Use -f and -t option to enable SSID Bruteforcing.
OPTIONS:
-e <ssid>
Tell mdk3 which SSID to probe for
-f <filename>
Read lines from file for bruteforcing hidden SSIDs
-t <bssid>
Set MAC adress of target AP
-s <pps>
Set speed (Default: unlimited, in Bruteforce mode: 300)
-b <character set>
Use full Bruteforce mode (recommended for short SSIDs only!)
Use this switch only to show its help screen.
d - Deauthentication / Disassociation Amok Mode
Kicks everybody found from AP
OPTIONS:
-w <filename>
Read file containing MACs not to care about (Whitelist mode)
-b <filename>
Read file containing MACs to run test on (Blacklist Mode)
-s <pps>
Set speed in packets per second (Default: unlimited)
-c [chan,chan,chan,...]
Enable channel hopping. Without providing any channels, mdk3 will hop an all
14 b/g channels. Channel will be changed every 5 seconds.
m - Michael shutdown exploitation (TKIP)
Cancels all traffic continuously
-t <bssid>
Set Mac address of target AP
-w <seconds>
Seconds between bursts (Default: 10)
-n <ppb>
Set packets per burst (Default: 70)
-j
Use the new TKIP QoS-Exploit
Needs just a few packets to shut AP down!
-s <pps>
Set speed (Default: 400)
x - 802.1X tests
0 - EAPOL Start packet flooding
-n <ssid>
Use SSID <ssid>
-t <bssid>
Set MAC address of target AP
-w <WPA type>
Set WPA type (1: WPA, 2: WPA2/RSN; default: WPA)
-u <unicast cipher>
Set unicast cipher type (1: TKIP, 2: CCMP; default: TKIP)
-m <multicast cipher>
Set multicast cipher type (1: TKIP, 2: CCMP; default: TKIP)
-s <pps>
Set speed (Default: 400)
1 - EAPOL Logoff test
-t <bssid>
Set MAC address of target AP
-c <bssid>
Set MAC address of target STA
-s <pps>
Set speed (Default: 400)
w - WIDS/WIPS/WDS Confusion
Confuses a WDS with multi-authenticated clients which messes up routing tables
-e <SSID>
SSID of target WDS network
-c [chan,chan,chan...]
Use channel hopping
-z
activate Zero_Chaos' WIDS exploit
(authenticates clients from a WDS to foreign APs to make WIDS go nuts)
f - MAC filter bruteforce mode
This test uses a list of known client MAC Adresses and tries to
authenticate them to the given AP while dynamically changing
its response timeout for best performance. It currently works only
on APs who deny an open authentication request properly
-t <bssid>
Target BSSID
-m <mac>
Set the MAC adress range to use (3 bytes, i.e. 00:12:34)
Without -m, the internal database will be used
-f <mac>
Set the MAC adress to begin bruteforcing with
(Note: You can't use -f and -m at the same time)
g - WPA Downgrade test
deauthenticates Stations and APs sending WPA encrypted packets.
With this test you can check if the sysadmin will try setting his
network to WEP or disable encryption. mdk3 will let WEP and unencrypted
clients work, so if the sysadmin simply thinks "WPA is broken" he
sure isn't the right one for this job.
(this can/should be combined with social engineering)
-t <bssid>
Target network
How to use MDK3
Using MDK3 is quite simple, since it comes with lots of help screens directly included.
You can easily access them by typing only mdk3
MDK3 displays the main help screen. To see all possible options, type mdk3 --fullhelp
To see only information for a specific test, type mdk3 --help followed by the test mode identifier (b, a, p, d, m, x, w, f or g)
Before you can use MDK3, you need to setup your wireless adaptor. As far as there are different driver architectures, the way to setup your adaptor may vary depending on which driver is in use. To make this procedure easy, it is recommended to use airmon-ng from the aircrack project, since it can setup almost every known driver correctly.
Read the documentation for airmon-ng to learn how to set your WiFi card into the proper mode.
IMPORTANT: You need to set your device to the channel where the target AP/client is, otherwise it won't work! This is a very common error.
To find APs and clients, it is recommended to use airodump-ng. Simply start it with airodump-ng [your_interface] first, to see the available stations. If you have decided on one CHANNEL where to run the tests on, you should restart airodump and set it to STAY on this specific channel, so your card won’t change channels anymore to find other stations. You can do this with airodump-ng -c [channel] [your_interface]
The good thing of using airodump-ng is, that you don't need to care about setting your card up correctly since airmon-ng and airodump-ng already did this job.
Your hardware is now correctly set up, and you can start using MDK3.
Another important notice for professional users: Some drivers do not correctly echo back injected frames to the system, thus your injected packets won't be seen if you sniff on the interface on which you are injecting. To check if the frames are sent correctly you need to setup another inteface on the same channel and sniff the injected frames with it! You can also use aireplay-ng's injection test to see if everything is alright.
b - Beacon Flooding
AccessPoints send out approximately 10 beacon frames per second. They are to identify the network. When you scan for networks, your card does in fact look for beacon frames on every available channel. With MDK3, it is possible to send those beacon frames, too. Therefor you are able to create as many networks as you like, always keep in mind, that those networks are fake, and nobody can actually connect to them. People will see those networks when they scan with their WiFi device. Windows does scan automatically as long as it isn't connected and shows an info, if a network is found. Additionally, this mode can be used to hide a network by generating thousands of fake networks with the same name as the original one. This mode has several options to set network name, i encryption, speed etc.
a - Authentication Denial-Of-Service
When a station connects to an AccessPoint, it needs to fulfill several steps of Authentication. The two basic steps are Authentication and Association. The first step starts the whole process and asks the AP if another station may connect to it, and lets the AP decide if the new client is allowed. A MAC Filter would deny this request if an unknown station would try to connect. In the second step, the encryption is checked. Most APs use the Open mode, so the Association Phase is always accepted, and the real check if a clients key is valid is done later (i.e. in the EAP phase for WPA). The weak point of this is, that you can start multiple requests and forget about them, but the AP needs to keep those request in its memory in order to complete it. This Denial-of-Service-Mode starts as much requests as possible and keeps track of the answers, the AP sends. You can execute this test on multiple APs at once, or you can select the intelligent variant, where mdk3 does itself keep track about clients, and even re-injects valid Data packets it intercepts from the network, so an AP may not be able to distinguish real and fake clients, and may start dropping legitimate ones to free up space.
p - Probing
The IEEE standard defines Probe packets. Those packets allow a station to send a request for a certain network into the air, with all matching APs responding to it. With those packets you can check, if an AP is in your range (ie. if you can reach it and it reaches you). Most APs have a feature called "hidden SSID". With a hidden SSID, a network cannot be "found" with Windows, and will be displayed on other Systems as "Hidden". The beacon frames emitted by those APs do NOT contain the networks name. Instead they either contain ZEROS for each character in the SSID, or only a single Zero. In order to connect to such a hidden network, an attacker must find out the networks real name. As far as the network's name is being transmitted in plaintext upon Association to the AP, an attacker could simply wait until some client connects to the AP or disconnect an already connected one with aireplay-ng or any other Deauthentication tool (mdk3 can do it too, Mode d), and wait for it to reconnect (which it usually does instantly). However, if there is NO CLIENT connected, the SSID stays hidden. With mdk3 however, you are able to try SSIDs from a Wordlist or via Bruteforce. It sends Probe Frames and waits for responses. If you hit the right SSID, the AP will respond to you, and it's name isn't hidden anymore. If you are lucky, the AP keeps the original length of the real SSID in its beacon frames. mdk3 will detect that and will only try SSIDs that match.
d - Deauthentication ans Disassociation
If a station wants to leave a network, it sends a Deauthentication packet to the AP to deregister itself from it. Additionally, the AP is allowed to disconnect stations when it thinks it is necessary (for example, the AP is full, and the oldest stations gets kicked from it to allow new clients to connect). As far as those packets are not encrypted our signed (if you are not using the new amendment IEEE_802.11w), an attacker can easily forge them to disconnect legitimate clients from your AP. mdk3 is capable of creating different types of those packets, with different options:
- Deauthentication from AP to client: mdk3 injects a deauthentication packet with the MAC Adress of the AP to the Station, telling the station is has been disconnected for unspecified reasons.
- Deauthentication from client to AP: mdk3 injects a deauthentication packet from the Station to the AP, telling the AP, the station is leaving the network.
- Disassociation from AP to client: mdk3 tells the client, it has been kicked because the AP is full.
- Disassociation from client to AP: mdk3 tells the AP, the client is leaving the network.
mdk3 listens on the current channel for Data packets, extracts the addresses of AP and Station from them, and sends one packet of each type. Every second, a status message is displayed, if something has happened.
mdk3 Usage Example
#1
Use the wireless interface (wlan0) to run the Authentication DoS mode test (a):
sudo mdk3 wlan0 a Trying to get a new target AP... AP 9C:D3:6D:B8:FF:56 is responding! Connecting Client: 00:00:00:00:00:00 to target AP: 9C:D3:6D:B8:FF:56 Connecting Client: 00:00:00:00:00:00 to target AP: 9C:D3:6D:B8:FF:56 AP 9C:D3:6D:B8:FF:56 seems to be INVULNERABLE! Device is still responding with 500 clients connected! Trying to get a new target AP... AP E0:3F:49:6A:57:78 is responding! Connecting Client: 00:00:00:00:00:00 to target AP: E0:3F:49:6A:57:78 AP E0:3F:49:6A:57:78 seems to be INVULNERABLE!
#2
You want to test if your own network is vulnerable to Denial-of-Service attacks. So first, you try a simple attack to see how your AP handles too many connected clients. Usually at a certain limit (128 or 256 clients), the AP denies additional clients. Cheap APs also tend to FREEZE and need to be resetted, so be careful with this! Let's assume your AP has 00:00:11:22:33:44 as hardware address, this is the first test:
mdk3 [your_interface] a -a 00:00:11:22:33:44 -m
a activates the Auth DoS mode. -a selects your target AP, -m makes mdk3 use only valid addresses to make filtering difficult. After a few seconds mdk3 may show one or mor of those messages:
- AP 00:00:11:22:33:44 is responding: Your AP is responding to mdk3's fake clients. This just lets you know, that your test is working.
- AP 00:00:11:22:33:44 has stopped responding and seems to be frozen after 157 clients: Your AP stopped responding to mdk3's requests. Check if your AP is still functional. If not, it is vulnerable to Auth DoS attacks, and needs to be reset if one occurs! You should request a fix from your vendor!
- AP 00:00:11:22:33:44 is reporting ERRORs and denies connections after 251 clients: Your AP stopped accepting new clients, but did not crash, and correctly denies new ones. Your network is now FULL, but stiull functional. However you cannot connect to this AP anymore until the fake clients from mdk3 time out and the AP accept new ones again. There is nothing wrong with that, this DoS condition is compliant with the IEEE 802.11 standard!
Afterwards, you may want to try the intelligent test, that makes it hard for your AP to distinguish fake and real clients. This causes a constant Denial of Service for new clients, as long as the attack is running. And as soon as a legitimate clients disconnects, he cannot re-join the network.
mdk3 [your_interface] a -i 00:00:11:22:33:44
mdk3 will print statistics each second:
Clients: Created: 67 Authenticated: 0 Associated: 0 Denied: 5461 Got Kicked: 0 Data : Captured: 0 Sent: 0 Responses: 0 Relayed: 0
- Created: Number of fake clients mdk3 currently handles and tries to connect and keep connected to the network
- Authenticated: Number of successful Authentication cycles
- Associated: Number of successful Association cycles
- Denied: Number of failed cycles (because AP is full)
- Got kicked: Number of fake clients that once were connected but the AP sent Deauthentication packets to
- Captured: Number of VALID Data packets that have been captured
- Sent: Number of Data packets that have been sent to the network with a fake clients identity
- Responses: Number of responses the fake clients got after sending data
- Relayed: Number of Data packets the AP accepted from the fake clients (AP forwards incoming packets so we know when it accepted one, if we intercept the forwarded one!)
In this example, the intelligent attack has been started about 10 minutes after the standard one. As you can see, the AP is STILL denying any new client! So be careful when you test a network that cannot afford some downtime!
#3
Let's assume you got a pretty important network, that is well secured. Lets say this network is only used a few hours each month, so an attacker may not be lucky to catch a client authenticating to it. You decide to add some extra security to that network by disabling the SSID broadcasting. That way an attacker may not be able to connect to it, since he doesn't know its SSID, and thus may not be able to run Authentication Denial-of-Service attacks. You select a pretty short SSID, but you add a special character to it, hoping that it cannot be guessed: aa1*
Let's test if this SSID can be decloaked by a Wordlist attack:
mdk3 [your_interface] p -f useful_files/common-ssids.txt -t 00:00:11:22:33:44 Waiting for a beacon frame from target to get its SSID length. SSID length is 4 Trying SSID: 3Com Trying SSID: AZRF Trying SSID: WiFi Trying SSID: mine Packets sent: 44 - Speed: 20 packets/sec Wordlist completed.
Sadly, your AP does only overwrite the SSID itself with ZEROS, not its length tag, so mdk3 knows, your SSID is only 4 characters long. Therefor, it tries only those words in the specified file, that a 4 characters long. Luckily, aa1* is not being found in the list, and mdk3 cannot find the hidden SSID. The attacker may now try to use Bruteforcing, since the SSID is very short. Let's say he already tried several character sets, and wants to finally try all possible characters:
mdk3 [your_interface] p -t 00:00:11:22:33:44 -b lnus
Waiting for a beacon frame from target to get its SSID length.
SSID length is 4
Trying SSID: aaaa
Trying SSID: aac&
Trying SSID: aag-
Trying SSID: aak<
Trying SSID: aao@
Trying SSID: aas^
Trying SSID: aaw{
Trying SSID: aa0{
Probe Response from target AP with SSID aa1*
Job's done, have a nice day :)
This time, mdk3 is successful. -b lnus means, start with lowercase, then numbers, then Uppercase and finally symbols. After about 2500 tries, the SSID has been found, and therefor does not add much extra security to your network. Consider using a longer one!
#4
mdk3 [your_interface] d -c 1,6,11 Disconnecting 00:04:0E:91:5C:56 from 00:1D:E5:7A:18:B9 on channel 1 Disconnecting 00:04:0E:91:5C:56 from 00:1D:E5:7A:18:B9 on channel 1 Disconnecting 00:04:0E:91:5C:56 from 00:1D:E5:7A:18:B9 on channel 1 Disconnecting 00:04:0E:91:5A:77 from 00:1D:E5:7A:15:CE on channel 6 Disconnecting 00:04:0E:91:5A:77 from 00:1D:E5:7A:15:CE on channel 6 Disconnecting 00:23:08:DD:4A:FE from 00:1D:E5:7A:43:00 on channel 11 Disconnecting 00:04:0E:91:5C:56 from 00:1D:E5:7A:18:B9 on channel 1 Packets sent: 117 - Speed: 16 packets/sec
mdk3 hops on channel 1, 6 and 11, and disconnects every station found there. Most stations try to reconnect, however, almost no communication is possible anymore, because they mostly get disconnected again, as soon as they re-request their IP-Adresses with DHCP and ARP, which triggers another Deauthentication cycle in mdk3. Use 802.11w if available or some IDS to at least detect such attacks on your network.
How to install mdk3
The program is pre-installed on Kali Linux.
Installing Musket modification (mod-musket-r1) on Kali Linux
git clone https://github.com/charlesxsh/mdk3-master.git cd mdk3-master make make install /usr/local/sbin/mdk3
Installation on Linux (Debian, Mint, Ubuntu)
sudo apt-get install git build-essential git clone https://github.com/charlesxsh/mdk3-master.git cd mdk3-master make sudo make install
mdk3 Screenshots
The program is a command-line utility.
mdk3 Tutorials
- How to perform selective jamming of Wi-Fi networks and clients (DoS attack on individual access points / clients)
- Three ways to put wireless interface in Monitor mode and Managed mode
- USB Wi-Fi Adapters with monitor mode and wireless injection (100% compatible with Kali Linux) 2021
Related tools
- wifijammer (65.6%)
- mdk4 (52.5%)
- Aircrack-ng (Tool) (11.7%)
- Router Scan (11.7%)
- infernal-twin (10.6%)
- OneShot (RANDOM - 3.7%)
Comments are Closed