Is there a way to permanent deauthenticate a device?

[hedgyman]

Theoretical question here.

I have been playing around with aireplay-ng to deauthenticate. I'm using a TP-Link WN722N card. I can send 70+ packets no problem in my test environment to deauthenticate a wireless device. When I tend to send more than 100-150 packets though I tend to get a lot of loss near the 80-90 packet mark and the device comes back online (also locks up my RPI and usb wifi). Just wondering if my wireless card is simply incapable of sending that many packets out or whether it's an issue with aireplay?

Is there a better way of disconnecting this device from it's associated network.

In my test environment I'm using a RPI running Kali linux and don't have the WPA2 key associated with the network (I know what it is, but I'm simulating that I don't have it).

I heard wifite is a good tool to use to crack wpa2 keys, but my assumption is that the RPI simply doesn't have the guts to crack WPA2 keys in a timely fashion. (atleast from my experience running aircrack on the RPI).

If that's the case, does anyone have any terminal commands to apt-get wifite? I'm getting more comfortable in running the RPI in headless mode and just using SSH or tightvnc to connect to the unit.

As always I thank everyone for any assistance they may be able to offer.

[ccunlimited]

you can use airstorm attack

[mmusket33]

Use mdk3
MTA

[hedgyman]

@mmusket33 I will do some reading on the mdk3 application, is it hardware intensive (I'll be running it from a RPI). My only concern is that the usb wifi card I'm using is going to puke out when too many packets are sent very quickly to the AP. It seems that the aireplay deauth attack fails after about the 80-90th deauth request to a specified mac address. Sending the deauth to the AP from my device mac seems to work no problem, but I know that the usb card pukes out a little because at points the devices attached to the AP do get a brief connection before dropping again. I may have to invest in a better usb card like an alfa card, but for testing purposes I would think the TP-Link card I have should be able to had such a request.

@ ccunlimited I haven't seen or read anything about airstorm attacks, do you have any links in the forums or to any wiki pages with further information?

As always you guys have pulled through to offer some assistance, I thank you for any and all support.

[slim76]

I'm going to state the obvious here, have you tried using aireplay and the -0 option.

[hedgyman]

@slim Yes I have been testing different aireplay options to pace the usb wifi card.

 aireplay-ng -0 20 -a "mac address of ap" -h "mac address of usb wifi card" mon0 --ignore-negative-one

I have tried the above code which doesn't lock up my usb wifi card at all, but then again it doesn't lock down the device in question it just does a global DoS attack on the AP. This allows devices to pop back up again on the network sporadically. My end goal is to knock down a specific device. This solution may work for another project I'm looking at down the road as long as the usb wifi card has the snot to ensure that no clients are able to reconnect at any point to the AP.

 aireplay-ng -0 20 -a "mac address of ap" -c "mac address of client" mon0 --ignore-negative-one

This will succeed in locking down the client device, but the issue is that when sending more than 80 packets consecutively the usb wifi card locks up and a full reboot on the RPI is required. (TP-Link WN722N wireless card using Atheros chipset)

As I'm fairly new to linux, I'm sure there's probably some syntax that I'm unaware of that may be able to pace the broadcasting of the packets/ set a duration to keep the device locked down. If this is possible I would love to know that syntax.

Otherwise I'm digging some more to see if there is another solution to gain access to the network to lock down the device. Currently aircrack-ng takes far too long for a brute force attack on a password. A simple 8 digit number PSK on WPA2 test network was taking over 24 hours to decipher. I know I could use a laptop (and I'm exploring that option), but currently the price point on the RPI is much easier for me to swallow and I'm certain it has the same capabilities, it's just my noobish linux background which is halting my progress on this project.

Hopefully there is a solution in the two posts previous.

Thanks for any and all help.

[slim76]

Try this:

aireplay-ng -0 0 -a AP_bssid --ignore-negative-one mon0

This should stop everything from connecting to the access point.

[mmusket33]

To ccunlimited

We attempted to download airstorm at:

wget http://hack4fun.initd.cz/repository/...-0.1-2-bt4.deb.

The link failed

If you have a link please post. If you have a copy please post it note: axifile is fast and easy. Just upload it and post the link.

MTC

[clone]

To ccunlimited

We attempted to download airstorm at:

wget http://hack4fun.initd.cz/repository/...-0.1-2-bt4.deb.

The link failed

If you have a link please post. If you have a copy please post it note: axifile is fast and easy. Just upload it and post the link.

MTC

this is a relatively old tool, but a copy is available here: http://up.backtrack.cz/data/wep-wpa-...torm.sh.tar.gz

[Nick_the_Greek]

To ccunlimited

We attempted to download airstorm at:

wget http://hack4fun.initd.cz/repository/...-0.1-2-bt4.deb.

The link failed

If you have a link please post. If you have a copy please post it note: axifile is fast and easy. Just upload it and post the link.

MTC

Hi there!
Here you go:
http://download.airodump.net/datas/w...torm.sh.tar.gz
http://pastebin.com/f64d6333e

[mmusket33]

Thanks clone and Nick:

We want to look at the coding and see if there is somerthing we missed embedded in the script. Soxorox2212 was working on the matter of reseting routers remotely but the thread got locked. We are still working on this to open up WPS locked routers.

We have found out that if you use the same wifi device to flood the router with mdk3 and at the same time you use the same device to run reaver - reaver can collect pins thru the mdk3 fog.

MTB

[Nick_the_Greek]

.....We have found out that if you use the same wifi device to flood the router with mdk3 and at the same time you use the same device to run reaver - reaver can collect pins thru the mdk3 fog.....

You're welcome and that's quite interesting!

[ccunlimited]

If you are interesting about wifi activity

[ccunlimited]

hi
I havent link for the airstorm in the moment

[Silverpyro]

@slim Yes I have been testing different aireplay options to pace the usb wifi card.

 aireplay-ng -0 20 -a "mac address of ap" -h "mac address of usb wifi card" mon0 --ignore-negative-one

I have tried the above code which doesn't lock up my usb wifi card at all, but then again it doesn't lock down the device in question it just does a global DoS attack on the AP. This allows devices to pop back up again on the network sporadically. My end goal is to knock down a specific device. This solution may work for another project I'm looking at down the road as long as the usb wifi card has the snot to ensure that no clients are able to reconnect at any point to the AP.

 aireplay-ng -0 20 -a "mac address of ap" -c "mac address of client" mon0 --ignore-negative-one

This will succeed in locking down the client device, but the issue is that when sending more than 80 packets consecutively the usb wifi card locks up and a full reboot on the RPI is required. (TP-Link WN722N wireless card using Atheros chipset)

As I'm fairly new to linux, I'm sure there's probably some syntax that I'm unaware of that may be able to pace the broadcasting of the packets/ set a duration to keep the device locked down. If this is possible I would love to know that syntax.

Otherwise I'm digging some more to see if there is another solution to gain access to the network to lock down the device. Currently aircrack-ng takes far too long for a brute force attack on a password. A simple 8 digit number PSK on WPA2 test network was taking over 24 hours to decipher. I know I could use a laptop (and I'm exploring that option), but currently the price point on the RPI is much easier for me to swallow and I'm certain it has the same capabilities, it's just my noobish linux background which is halting my progress on this project.

Hopefully there is a solution in the two posts previous.

Thanks for any and all help.

If it's running WPA2 passphrase encryption as I believe you said you can't brute force the minimum 8 character passphrase with any computer on the market with any timely effect. The average computer using CPU based brute force will take over 200 centuries to decypher an 8 character WPA2 passphrase and GPU based brute force will only cut the time down to around 1 quarter of that depending on what GPU you are using. I have seen a 63 character passphrase brute forced with GPU based brute force done in less than 7 days but the guy was using a cluster of servers each with 5-7 video cards and spent probably around $300,000 or more on the setup. The only feezable way to crack WPA2 is with a dictionary attack and hope the person is not smart enough to make the passphrase totally random. Then again these are simulated environments. In the real world the best password is a totally random mixture of upper and lower case letters, numbers and any special characters that the encryption protocal will accept.

[Name Taken]

MDK3 is pretty good at blacklisting a MAC address of an AP or client and continuously deauthenticating any device connecting to it or it connects to. And lol @ trying to crack WPA2 with a Raspberry Pi. Even with a desktop CPU it's pretty futile. For comparison, a modern mid range PC can crack about ~5K/second, vs. 150K/second with a single R9 280X. A Raspberry Pi cracks at like 50/second?

[mmusket33]

To Silverpyro,

A better view of WPA is that you cannot break thru brute force cryptgraphically dense keys. BUT most users pick numeric strings in over 50% of their keys and over 90% of those are ten or less. When reaver was king we were not bound by brute force constraints and got a good view of how users picked their keys. We break WPA all the time thru brute force using elcomsoft and two gpu's.
WPA is nearing walking dead status. Within 5 years computing power will be such that WPA can be broken with mid-range computers not just extreme high end banks of gpu's linked to windows 8.
MTeams

[black_box]

My only real question here would be why would you want to deauth a device from the AP? Given you dont know the WPA i could see using deauth to get a handshake or to start gathering data in the instance that WEP is the key being used deauth would allow for more data to be collected and making it faster to crack the key. The problem I see is that if you disconnect a machine from the network why keep it off the network? I dont see a good reason for that unless your spoofing the mac in which case then you still wouldnt need to do more then just deuath the machine and connect with spoofed mac in its place. I guess Im just trying to find a real reason why you would want to keep a machine deauthed from the network. In my experience if a machine cant stay connected to a network odds are IT will be called pretty fast to find out why in which all your doing at that point is exposing yourself to being "caught". Just my thoughts.