script - Listening for client mac (wifi) - feedback request

Heya guys & galz,

I would like to ask some kind souls whether they may be interested in wasting a bit of time in checking out, and commenting on, a script made to check for the presence of client macs.

Basically the script uses tshark to check for probe requests, parses the info to a temporary file from which info is taken and shown on screen.

I am particularly interested in what the feelings are on the scans for specific MAC addresses / specific probed ESSIDs as well as the white and black list usage.
The actual listing of probing MACs from phones / wireless NICs seems to work pretty OK.

http://i94.photobucket.com/albums/l1...psczzaydvg.png

For general usage the basic info is sufficient, however I would suggest to read the full help (option -H).

http://i94.photobucket.com/albums/l1...psag8mlshr.png

The most used option is likely as follows ;

Code:

---

./shee.sh -i mon0 -M 3 -dus

---

http://i94.photobucket.com/albums/l1...psihjwxdc3.png


I would greatly appreciate feedback and (constructive) criticism on how to improve what has been quite a bit of fun writing & testing ^^

Some error checks are included and have done quite a bit to make it easy to use, however if you run into errors / bugs, your feedback truly appreciated.

Thanks !

If I manage to motivate myself enough I might consider making a github, but for now the below is fine ;)
download;
http://www.mediafire.com/view/vz2nea6bv1hq779/shee.sh


EDIT
--------
The vendor information is very dependant on an upto date oui.txt as I recently found out when testing on new Samsung S6 mobiles, so I would recommend getting the latest list from ieee.standards.org and pointing the script to same (line 46), or use the -U switch and download ;

Code:

---

./shee.sh -U

---

So i actually had a chance to play with this last night and i must say it is very very nice! I mean like really spot on in functionality, it hasn't broken a single time and everything works just as it should so i give it a A+

One thing i did and you might want to put a option for it is record all the packets in the -M 3 options. It was pretty simple i just added this to the top.

Code:

---

PCAP_FILE="$LOC"packets.cap

---

And added this to the end of the tshark command.before the 2> /dev/null

Code:

---

-w $PCAP_FILE -P

---

Now you have to get a github account and put this up so i can always grab the newest version ;)

Thanks!

I like how the scan for a specific probed ESSID updates the RSSI in real time. And the use of color there is really helpful. Also you can make the space between columns in Mode 3 narrower so more info can fit in a smaller window.

Thanks for the feedback guys !
The pcap idea is not a bad one, logging of output can be done with the -l switch, but saving the whole packets may actually be better/easier to parse !

I was having trouble with spacing and parsing as some info/essids contains multiple words, I will revisit the layout and see if I can get the spacing and parsing to play nice with printf fixed spacing instead of echo + tabs.. might also remove the year from date/time..will save a bit of space ;)

Thanks again for the input!

To Tape:
We like your work so do not think in any way there is criticism here.

MTeams is unsure how to employ your tool in an exploit.

However we wish to draw your attention to the following:

https://forums.kali.org/showthread.p...ighlight=clear

In fact with the rise of androids these WPA keys can be regularly found floating around in clear text. We found two last week. We arrived in a new location turned on airodump-ng and the WPA keys were sitting on the screen. The android phone was probing for a WPA key not an ESSID.

Your approach may be more effective then using airodump-ng. Furthermore our affiliated Musket Team C Programmer has come across an additional exploit floating around in clear text which we have to clear with him/her prior to releasing. However you might be interested in altering your script to take advantage of the already outlined exploit as
seen in the link above.

Again this is not a correction just a possible direction.

In closing keep up the good work.

MTeams

Heya mmusket33,
Thanks for checking out the script, as I am sure you noticed, it only catches the probe requests, so actually it misses
a few Client MACs, such as those already connected / connecting.

Those do eventually show up, but it is a point I am trying to get sorted with better filtering of the tshark commands.


As for 'How to employ in an exploit' .. well, I never really considered an exploit, I was basing the script on
getting info on who was (coming) around the house, gathering intel on that, and well, lets say nothing else.

It has been a long time since I contributed anything at all, hence my release of this script, which I find amusing at least.

Your idea of checking probed ESSIDs for accidentally entered WPA keys is kinda 'out there', however I can imagine that
some idiot has done it ! So why not check ?! (so many idiots out there, myself included..)

It wont be a part of the script for a while, but I will keep that in mind for future reference when checking probed essids.


Thanks for testing !!

To Tape,

As we noted in our original posting finding WPA keys in clear text is NOT a rare event. We see WPA keys weekly floating around in our csv files which is why we wrote the program to begin with as a lab tool, later we released it for general use.

As soon as our affiliated C-Programmer allows it, will will release more on this matter.

MTeams

Well its definitely an interesting observation, cant say I have seen anything looking like passwords from local 'scans' in the probe requests, but will keep an eye out now ;)

thanks for the script , it is working like a charm and detect very fast any kind of conection atempt.
I love the ascii signal intensity bar :D
bash is wonderfull :p
The options are clear and well explained so it is quite easy to use.
You could maybe integrate the mode monitor mangement with automatic mode monitor enabling if only one interface is present in the system. i can pass you some already made function for this if you want.
thanks for sharing with us.

PS: i have some troubles interpreting this up and down tag :
https://www.wifi-libre.com/img/members/3/shee2.jpg
mi wifi interface wlan0 is up but shows as down.
i am connected to the internet with it. Does this up and down tag means that it is avalaible for using with shee?
other stdout from kali

Quote:

---

_ _
| | By TAPE | |
___| |__ ___ ___ ___| |__
/ __| '_ \ / _ \/ _ \ / __| '_ \
\__ \ | | | __/ __/_\__ \ | | |
|___/_| |_|\___|\___(_)___/_| |_|
> Wireless Interface(s)

IFACE MAC ADDRESS STATUS
----- ----------- ------
wlan0 4C:BB:58:XO:XO:XO DOWN (Mode:Managed)
wlan1mon 00:1A:EF:XO:XO:XO UP (Mode:Monitor)

---

it says down but th interface is up

Heya kcdtv

Thanks for checking the script, I always enjoy a bit of bashing :D

There is actually a hidden option in the latest version (you may need to check the link again) which I put in
for simple testing ..

Code:

---

./shee.sh -a

---

will take the first found wireless interface, put it in monitor mode, and start listening for all unique probe requests.


As for the UP / DOWN issue.. my checks on this were very .. very rudimentary.. :|
It is however possible that your output is different from what the output is on Kali which will then impact on my parsing commands..
which makes me wonder *** I have done considering you say you running on Kali on the 2nd stdout ... :\


Could I ask you to post the stdout of ;

Code:

---

ifconfig wlan0
ifconfig wlan2

---

(and by the way.. your 2nd stdout message is not hiding the MAC addresses.. ;) )


Thanks again for your time spent on checking my script and I will deffo check the bugs ! Thanks !

Quote:

---

As for the UP / DOWN issue.. my checks on this were very .. very rudimentary.. :|
It is however possible that your output is different from what the output is on Kali which will then impact on my parsing commands..
which makes me wonder *** I have done considering you say you running on Kali on the 2nd stdout ... :\

---

:D

Yes, the first stdout (on the snapshot) is under xubuntu 15.04 and the second is with Kali, I rebooted to check that it was not an issue with ubuntu.

If i look on the code that where the check is done:

Code:

---

STATUS=$(ifconfig $i | sed -n '2p' | grep -io up)
if [ "$STATUS" != "UP" ] ; then STATUS=DOWN ; fi

---

* i am right now with thje internal interface wlan0 (the one that gives problems) connected to the Internet.
full stdout for wlan0 is

Code:

---

wlan0    Link encap:Ethernet  HWaddr 4c:bb:58:0f:ba:aa 
          inet adr:192.168.2.103  Bcast:192.168.2.255  Masque:255.255.255.0
          adr inet6: fe80::4ebb:58ff:fe0f:baaa/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Packets reçus:13293 erreurs:0 :0 overruns:0 frame:0
          Paquetes TX:13117 errores:0 perdidos:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000
          Octets reçus:15315807 (15.3 MB) Octets transmis:1349829 (1.3 MB)

---

and if i use the pipe with sed that you used in the script it gives me

Code:

---

kcdtv@profezorapplestruff:~$ sudo ifconfig wlan0 |  sed -n '2p'
          inet adr:192.168.2.103  Bcast:192.168.2.255  Masque:255.255.255.0

---

and indeed there is no "up/UP" on this line...

* second interface, rtl8187l from loopcomm, USB, the same than yesterday, and has yesterday , it is NOT connected

Code:

---

sudo ifconfig wlan2
wlan2    Link encap:Ethernet  HWaddr 00:1a:ef:41:3c:ba 
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          Packets reçus:0 erreurs:0 :0 overruns:0 frame:0
          Paquetes TX:0 errores:0 perdidos:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000
          Octets reçus:0 (0.0 B) Octets transmis:0 (0.0 B)

---

and on this second line we have

Code:

---

UP BROADCAST MULTICAST  MTU:1500  Metric:1

---

So the issue is that ifconfig stdout changes a little if we are connected or if we are not connected.
-If the interface is not connected to the Internet, everything is fine as the second line of ifconfig stdout is indeed the one with "UP BROADCAST MTU etc.."
- if we are connected : the address resolutions for IP4 is stdouted on the second line and the line with "UP BROADCAST" go downs and became the fourth line

i was thinking that maybe "awking" the first field with space as a separator will keep it simple with a single pipe and should work in any case, wherever the line is.
And by checking just the first field I assume that there shouldn't be any unwanted match with a line.

Code:

---

STATUS=$(ifconfig $i |  awk -F' ' '{ print $1 }' | grep -io up)
if [ "$STATUS" != "UP" ] ; then STATUS=DOWN ; fi

---

http://pix.toile-libre.org/upload/or...1437317443.png

Quote:

---

(and by the way.. your 2nd stdout message is not hiding the MAC addresses.. )

---

They were spoofed. For sure, for sure.... :p
Thanks, i modified that. :)

bye & take care

Dude, that is a friggin awesome response :D

Will get on it and fix the checks on where to look for the 'UP'.

I only run in VMs and only Kali these days, so did not check all as closely as I should, thanks for the catch and the great explanation on how to remedy it.

Worthy of an honourable mention :D

:D I don't know if that's worth an "honorable mention" - that's really a detail in the script and it was not affecting at all the general behavior - but thanks. :D

Quote:

---

I only run in VMs and only Kali these days, so did not check all as closely as I should, thanks for the catch and the great explanation on how to remedy it.

---

I wouldn't have noticed it either normally : most of the time i am connected through Ethernet cable and I barely switch on the repeater.
It was good luck that i was using it when i tried shee :)

hehe :D

well its not like we get you a gold statue and remember what a great person you were when u kick the bucket...
I will do one better than that..I will mention your fantastic contribution to this awesome bit of code at the end of an unknown text file hosted at an as yet to be determined location :D

Basically though, I am really very happy that some peeps take the time to look at the code and give pointers that really make sense,
thanks so much for your time kcdtv.

I have included your idea on the awk check of the ifconfig setting.

Any other ideas or improvements appreciated, it has been fun getting this script off the ground...
I was toying with the idea of including a bluetooth check following an iPhone identification as iPhone wifi & bluetooth are close in what I have found in MACs..
So basically one would only need to check the last 2 octects of the wifi MAC address seen to get the Bluetooth address of the apple device..

But this seemed a little too difficult using fang or the like...

Hey Tape, brilliant script -- just wanted to mention your current version (Last edit 25-07-2015 23:45) and your previous version (Last edit 28-06-2015 23:00) both share the same version number -- v0.3b

Quote:

---

Originally Posted by Rarity

Hey Tape, brilliant script -- just wanted to mention your current version (Last edit 25-07-2015 23:45) and your previous version (Last edit 28-06-2015 23:00) both share the same version number -- v0.3b

---

Whoops, was supposed to lose the Bravo.. but had a few sherbets when last updating.. :D

Thanks for the heads up, fixed.

Giving this a spin now. I'm working on a similar project aggregating the thsark RSSI data from 3 Alfas, for which I pre-calculate the location of each using an old TomTom GPS receiver. That gives us our 3 reference points for basic, decently-accurate Wifi RSSI probe triangulation using some of the equations described here.

Thus far, my crude Python -> Processing (for visualization of the aggregated plot points) hackjob can plot a rough position of an endpoint, with an update frequency reliant only on how fast/numerous the endpoint is sending the probes. I've yet to work in the math from the above and other references, so the current implementation is only using the known values of the 3 fixed Alfa points and the RSSI values reported by each (thus, the current measure of distance is ONLY signal strength which is fine for testing for obviously not for real-world application).

I'll be following this one closely. If you do throw it on Github where I can fork it, all the better.


-nopex

Kali linux 2.0 --> did not work :confused::(

Quote:

---

Originally Posted by [email protected]

Kali linux 2.0 --> did not work :confused::(

---

Hey yopmail lovah,
Sorry to hear you having trouble, I was hoping it was gonna be an easy run with the new Distro ;)
However I am going to need a wee bit more information to help you out.

The script runs fine on Kali 2.0 following my tests, so please give the input you used to run the script and the errors (if any) that were given.

Thanks !

Unfortunately it appears that some change in the way tshark processes fields (the -T fields options) has fubarred the main scanning part.


So regret to say that until I have managed to resolve that the script is not going to work :(

Not sure what changed or why, but possibly an update that I did not have when above yopmail user above did have it
caused a change..

Basically the main part of the script from which info was parsed was ;

Code:

---


tshark -i $IFACE -n -l subtype probereq -T fields -e wlan.sa -e radiotap.dbm_antsignal -e wlan_mgt.ssid -E quote=d 2> /dev/null

---

This worked fine uptil, well not sure when, havent used it for a while, but safe to say I suppose it hasnt worked for a bit :(

Just running the tshark with the subtype works fine;

Code:

---

tshark -i $IFACE -n -l subtype probereq

---

So seems to be the fields but cant yet figure out why.

If anyone has any ideas on what might have changed with this would appreciate news, if not I will plod on and continue testing.

There should be somewhere documentation about this change... or some issue somewhere on a forum... If i see something i will tell you.

try this one / if you define a capture-filter (subtype probereq) you need the -f switch and the quotes.

Code:

---

tshark -i $IFACE -n -l -f "subtype probereq" -T fields -e wlan.sa -e radiotap.dbm_antsignal -e wlan_mgt.ssid -E quote=d2

---

Quote:

---

Originally Posted by someone_else

try this one / if you define a capture-filter (subtype probereq) you need the -f switch and the quotes.

Code:

---

tshark -i $IFACE -n -l -f "subtype probereq" -T fields -e wlan.sa -e radiotap.dbm_antsignal -e wlan_mgt.ssid -E quote=d2

---

---

Dude I could kiss you.. (don't worry I'm a decent looking guy)

Thanks very much for your pointer on the correct syntax, it has done the trick and now all seems to work as it should, Yay !

Will test the various functions and update the script accordingly.


Thanks again !


edit
------
tested on Kali 1 & Kali 2
The above adjustments to the tshark command worked out peachy and all is right with the world again :)

Download link unchanged, version now 0.4

http://www.mediafire.com/view/vz2nea6bv1hq779/shee.sh

Nice! :cool:
Thank you someone-else.
XO XO :p :D

Tape, thanks for the update!

I think this would be great if we could somehow attribute the devices hostname along with the MAC address.. but that information isn't included in the probe request. Is there possibly another way to acquire the hostname?

Quote:

---

Originally Posted by Rarity

Tape, thanks for the update!

I think this would be great if we could somehow attribute the devices hostname along with the MAC address.. but that information isn't included in the probe request. Is there possibly another way to acquire the hostname?

---

I don think so without the client being associated, would have to think about it, but think a no-go for the script in its current form / intended scope.

What exactly is your idea / requirement ? Its sometimes easier to make a quick and dirty script for a single purpose/use..

Sorry for the delayed response. My proposal is for further identification.. pairing "Mark's iPhone" with aa:bb:cc:dd:ee:ff is a lot more informative than a MAC address alone.

Quote:

---

Originally Posted by Rarity

Sorry for the delayed response. My proposal is for further identification.. pairing "Mark's iPhone" with aa:bb:cc:dd:ee:ff is a lot more informative than a MAC address alone.

---

Hey Rarity,

Well from what I have seen you cant get that info from the packets without the device being connected to a network.
Must admit I have not looked into it very well and not sure from which stage of association the hostname info is available / broadcast,
might dig in on that later.

I was toying with the idea of incorporating an iPhone bluetooth mac address brute-forcer (redfang or the like) as from what I have seen
iPhone wifi & bluetooth MAC addresses only differ in the last 2 octets, but this can still mean a long time to scan all possibilities.
Also heavily scanning bluetooth can impact your 2,4gHz wireless, so might cause other issues, but could be an idea for a separate mode.

So many ideas, so little time.. bah.. the irony of life..