Fang_Shadow

Active Members
  • Content count

    31
  • Joined

  • Last visited

About Fang_Shadow

  • Rank
    Hak5 Fan
  1. Try LED M (magenta aka purple)
  2. Responder deb file can be found here https://github.com/F9Alejandro/packages just place it in your tools folder when in arming mode and then just unplug and plug back in while still set to arming mode to install
  3. it is because the linux box can't get the correct time and date, my packages repo says last updated 15 days ago because i pushed via my bashbunny to github. Don't worry about the time being off and or date because you will need to change the settings every time you plug it in.
  4. I will test it when I get home then will edit this post once I have confrimed anything EDIT: So I tested QuickCreds on my computer, but can't seem to get anything from it (don't know if a windows 10 patch fixed this exploit or not), it doesn't obtain anything and just sits at the white double flash stage, nothing further. As for the red blinking, did you look up what FAIL 1 looks like vs FAIL 2. FAIL 1 is because of dependencies and is a slow red pulse, FAIL 2 is a double pulse and means it can't get an ip address for the target machine (allow the device to give dns automatically network adapters -> IBM RDNIS -> IPv4 -> DNS Auto) EDIT 2: NVM found out the issue with mine, had to use a bogus network dir for it to spoof and get the hash
  5. Correct they impacket is the only one with a setup.py responder doesn't need any setup it just works, all that is needed is to look for the REQUIRETOOL fields and make sure impacket and responder are there. Then to run the test server and such you need to basically cd into the dir with the examples, if not quickcreds should do it for you.
  6. I have a dev file for responder on my github and dev has posted a link for impacket on one of the other threads https://github.com/F9Alejandro/packages
  7. did you run setup.py in the impacket base dir on the linux side of the BB, just to be sure that it is installed correctly. if so then there is possibly something else going on in the background that is causing it to fail.
  8. I have an updated dev file on my github https://github.com/F9Alejandro/packages just place in your tools folder in arming mode, unpkug, the plug back in for it to install, be sure to remove the old responder from the /tools/ folder on the linux side before install.
  9. I only just looked at the kali linux version of responder, yes that one is the only one being majorly kept up to date it seems. i have built a responder.deb package based on that version on my bashbunny (windows kept deleting items from the git repo). It should be up soon on my github, link will be posted once done. EDIT: uploaded .deb file here is the link https://github.com/F9Alejandro/packages Just place the .deb file in the tools folder w/ BB in arming mode and then just unplug and replug in the BB to install.
  10. Did you go to the tools dir for impacket. /tools/impacket/examples did you run it as a python script? Python smbserver.py (folder to show on smb) (dir to share from linux) ex. Python smbserver.py temp /root/tmp Grab the github repository and drop the folder just before the python scripts into the tools dir in arming mode. So Responder-master becomes responder with all the python scripts and what have you in that folder. After unplugging the BB I and plugging it back in it should install the tools automatically and delete the folder responder from the tools dir in mass storage "udisk"
  11. bunny_helpers.sh

    The extensions is bunny_helper.sh you don't need that file as they are already end variables like, GET TARGET_IP or GET TARGET_HOSTNAME, REQUIRETOOL impacket. These are working by default in the extensions folder of the payload library.
  12. Udisk isn't mounted when storage is used as an attack mode, if it was HID or Ethernet it would from what I've seen. To mount Udisk type the following: mount -o sync /dev/nandf /root/udisk Then you should see what is in your udisk. Your tools installed should be under /tools/ not under /root/udisk/
  13. I dont think it needs to go inorder as it is just aditions and changes from what I've seen. Then again this will be the second firmware update so I dont know what changes are made or persist.
  14. bash bunny

    You could have bricked your device from completely booting/running the files to allow use. Possibly from incomplete download of firmware, did you check the hash against the download to see if it was a match?
  15. Subnet is 255.255.255.0 for the BB