Am I watching a hack

[n-quire]

I was running Wireshark an watching some of the packets comming off my computer. While doing that I noticed some odd packets on my neighbours open(OPN) access point.

It's always

source = Apple_e5:8d:28

dest = Netgear_13:a8:92

The traffic is a combination of \

"Association Request"

"Action" (I can see a Block Ack rule - not sure if that's relevant)

"Key (Message 2 of 4)" (always 2 of 4, never any other messages)

"Authentication"

"Disassociate" (Reason code: Disassociated because sending STA is leaving...)

[n-quire]

(sorry, didn't mean to submit then)

Those packets come a different orders and different numbers. Some times there's 3 Key's, sometimes 10.

The thing that has me really confused is the fact that I only see "Message 2 of 4"... where are the other three?

I filtered on this connection and left it running all day. No other types of packets appeared. Just these ones over and over again.

[digip]

Probably normal beacons and association and disconnection from an iPhone or iPad device that recognizes the router name, but is generic and doesn't have authentication to connect for what its truly looking to connect to(IE: has a saved AP name of say, Linksys that at one time used WPA or such, and the one its connecting to, doens't need it if it IS really open). Its probably trying to reconnect, and getting disconnected because its not truly open or the info it has on record for the AP name, or may have MAC address filtering and is kicking it off the AP. Shouldn't be of any concern though. You can look up specifics on things like the STA message on the wireshark site for more info though, or just google for what the frames mean. It may be related to info in this archived post:

{0x08, "Disassociated because sending STA is leaving (has left) BSS"},

That info may be out dated though..

https://www.wireshark.org/lists/ethereal-dev/200403/msg00612.html

[n-quire]

Thanks digip. So it's general noise rather than "real" activity. That makes sense. If it was a hacker I don't know why they persist in trying something that obviously doesn't work.

[digip]

Devices, by default for most, will store AP names, and continually reconnect to them, which is also why we can use deauthentication attacks to capture handshakes, etc. That said, this may be normal traffic though. There are filters to look for specific sending of deauth packets, but I don't remember them off the top of my head. A quick google should return capture filters or after capture filtering to view them. Again, it may just be normal traffic though. I think we had a topic on this subject before in the past where someone may have even posted the filter for looking for just deauth packets. Searching the forums might have the answer. Some of the other wifi gurus might also shed some light on it and know more about whats a true attack, vs normal traffic, if you post some of the captured traffic info or screenshots from wireshark.

[n-quire]

Here's a few screenshots.

First, a sample of the packets. All I filtered on was the the ether host and ether dst. So it should be all the traffic for that machine.

The Action is always the same Block Ack Policy

And finally, the Key Message always has the same WPA Key Data, the WPA Key Nonce and WPA Key MIC change.

(I assume the WPA Key info can be used for something, but I am not advanced enough to get anywhere without an Ack handshake).

[digip]

If it's an open AP, WPA key info shouldn't even be seen. Seeing what you posted, tells me it's a WPA enabled router, and not an Open AP as you mentioned in the first post. With WPA, there is a 4 way handshake for authentication, which is also why you are seeing the EAPOL in there. My guess is someone is trying to connect possibly, but more than likely they just have the same stored AP name and it may be automatically trying to connect when they don't have the stored key.It could also be blocking the Apple device trying to connect via MAC address filtering. If you have linux and the aircrack suite installed, you could capture with airodump, and if someone is deauthing them and successfully re-authenticating, it will eventually see the 4 way handshake and tell you, but it could also capture it if you have it running, before they connect normally.

To be sure if its someone being attacked though or continually being deauthed, is hard to say. It could be the router kicking them via MAC address filtering, which it will do repeatedly. That might look like a deauth attack, but to me, a deauth attack in general, should be a flood of the same deauth packets in constant spurts or just continuously, like with mdk3 or aireplay. Using a filter to display only the deauth packets in real time, if it was a flood, you would see it fill up really quickly vs what may just be normal traffic. Without being the person sitting at the Apple device and monitoring their own connection, it's speculation at best for now.

I assume the WPA Key info can be used for something

This is for another topic, but yes, if you captured the the entire 4 way handshake, you could use tools to brute force authentication for the AP. With WEP, its already a dead and broken authentication method for wifi and takes less than 3 minutes or so depending on your capable hardware, to break in. With WPA, its more a time trade off of how long it takes to try every possible entry until you find a match since it can only be brute forceds. If they have WPS (wifi protected setup) enabled, you could use reaver to break in much quicker using the PIN method for association with the AP. Those are all things for a different topic, and most of which has been answered more than enough times on the forums already...