Results 1 to 28 of 28

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

  1. 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.



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



    The most used option is likely as follows ;

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



    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
    Last edited by TAPE; 2015-06-24 at 21:31.

  2. #2
    Join Date
    2015-Jun
    Posts
    7
    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!

  3. #3
    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.

  4. 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!

  5. #5
    Join Date
    2013-Jul
    Posts
    844
    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

  6. 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 !!

  7. #7
    Join Date
    2013-Jul
    Posts
    844
    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

  8. 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

  9. #9
    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
    bash is wonderfull
    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 :

    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
    _ _
    | | 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
    Last edited by kcdtv; 2015-07-19 at 13:56.

  10. Heya kcdtv

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

    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 !

  11. #11
    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 ... :\


    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

    (and by the way.. your 2nd stdout message is not hiding the MAC addresses.. )
    They were spoofed. For sure, for sure....
    Thanks, i modified that.

    bye & take care

  12. Dude, that is a friggin awesome response

    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

  13. #13
    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.
    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

  14. hehe

    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

    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...
    Last edited by TAPE; 2015-07-25 at 22:20.

  15. #15
    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

  16. Quote Originally Posted by Rarity View Post
    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..

    Thanks for the heads up, fixed.

  17. #17
    Join Date
    2015-Aug
    Posts
    2
    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

  18. #18
    Kali linux 2.0 --> did not work

  19. Quote Originally Posted by [email protected] View Post
    Kali linux 2.0 --> did not work
    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 !

  20. 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.

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

  22. #22
    Join Date
    2015-Apr
    Posts
    15

    Wink

    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

  23. Quote Originally Posted by someone_else View Post
    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
    Last edited by TAPE; 2015-10-10 at 10:58.

  24. #24
    Nice!
    Thank you someone-else.
    XO XO

  25. #25
    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?

  26. Quote Originally Posted by Rarity View Post
    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..

  27. #27
    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.

  28. Quote Originally Posted by Rarity View Post
    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..

Similar Threads

  1. Replies: 0
    Last Post: 2018-09-10, 14:26
  2. [Support Request] Installing WiFi Dongle
    By dennisblah in forum TroubleShooting Archive
    Replies: 0
    Last Post: 2016-08-24, 19:12
  3. Fern Wifi Cracker - Probing for client macs problem
    By steven6282 in forum General Archive
    Replies: 1
    Last Post: 2015-05-17, 08:34
  4. Fern Wifi Cracker - Probing for client macs problem
    By steven6282 in forum TroubleShooting Archive
    Replies: 1
    Last Post: 2015-05-17, 08:34
  5. Replies: 0
    Last Post: 2014-06-22, 22:27

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •