Jump to content


Active Members
  • Posts

  • Joined

  • Last visited

Everything posted by Fang_Shadow

  1. no i am saying to choose one or the other, but only with one attack mode (ethernet OR storage; not both)
  2. On the bashbunny itself or the host computer the bashbunny is plugged into, please note that not all computers come with the jre installed and would likely not work because of this.
  3. Remember that linux uses both RNDIS_ETHERNET and ECM_ETHERNET, since it wants to be compatible with both windows and unix(mac). Has the usage of both storage and another attack mode work at the same time before on linux, or could be something different.
  4. Really quick note of something I noticed with flashing bashbunny from 1.0 to 1.3, It was in a wall to usb adapter/cube and got stuck at a solid red (no idea what it means possibly failed or error) unplugged it and plugged it back in and it seems to be working properly again. Just for others that might experience the same issue.
  5. 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
  6. 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.
  7. 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
  8. 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.
  9. 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
  10. 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.
  11. 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.
  12. 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.
  13. 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"
  14. 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.
  15. 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/
  16. 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.
  17. 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?
  18. Subnet is for the BB
  19. the device is being mounted as read-only, find the device name unmount then remount with '-o rw' (-o is option and rw is read-write)
  20. DFU is recovery mode, and the green light turns off after a few seconds right before the next stage which is the load what ever switch you are on.
  21. I made some changes to the payload, instead of cmd calling powershell to open another cmd, i have it opening a powershell as admin (more tools). And I have made another section which closes all open cmd and powershell just in case one lingers for what ever reason, oh and of course clearing the run dialog.
  22. Is the device getting enough power, sometime if the device is connected to the computer instead of a powerblock like the iphone wall based usb block, sometimes the device doesn't get enough or faulty power and causes it to do a sort of loop to try and fix itself. Instead of letting do this loop, why not force the BB into DFU mode from plug in to the block after the green light goes off, unplug do this 3 more times then just leave it. it should go through the flash process correctly. I have never had this issue as of yet, but this is just a theory of what is going on with your devices.
  23. Would going into the bunny.service /lib/systemd/system/bunny.service and add KillMode=process ? Edit: With the bunny_framework edit to fork and the service edit adding of KillMode=process seems to work, blue light is still flashing after reboot in arming mode. Now on to test some payloads.
  24. nano or vi into the file located at /usr/local/bunny/bin/bunny_framework, it is the last hop in the file at the very end and changing it to "hop &"(without the double quotes). I don't recommend it for now though and just wait for 1.2 as doing so will have effects unintended or harmful to the BB. I had an issue and restored it 3 times after changing the bunny_framework file (just me most likely), and the LEDs won't work properly after the change.
  • Create New...