Jump to content

rastating

Active Members
  • Content Count

    12
  • Joined

  • Last visited

Everything posted by rastating

  1. Have you checked out the guides at http://wiki.bashbunny.com/#!./index.md#Connecting_to_the_Linux_Bash_Bunny_Console_from_Linux/Mac and http://wiki.bashbunny.com/#!././index.md#Sharing_an_Internet_Connection_with_the_Bash_Bunny_from_Windows ?
  2. 172.16.64.10 will be the IP address your host machine has been assigned. The IP address of the bunny will be 172.16.64.1 Default values from the wiki are: Username: root Password: hak5bunny IP Address: 172.16.64.1 DHCP Range: 172.16.64.10-12
  3. It wasn't me that sent the PR, I only realised there was an existing one once I was opening one haha @gmonk no problem :) got to share the knowledge!
  4. @TTommy - just went to create a pull request with the fix for this and found it's already been submitted! You can find it here: https://github.com/hak5/bashbunny-payloads/pull/17 If you want to apply the changes manually in the meantime, you can see the changes made here: https://github.com/hak5/bashbunny-payloads/pull/17/files
  5. I tested using the previous version of the payload, that installs the cmd files and vbs file into the root. It looks like you're using the latest version which is supposed to keep everything inside the switch* folder. If you want to use the previous version, you can grab the files from commit dcace71 on GitHub / this link: https://github.com/hak5/bashbunny-payloads/tree/dcace71e99bfb9e69cd02c30b4bb6db60f93d9d4/payloads/library/usb_exfiltrator I'll give the new version a test too, and see if I can replicate the problem / try to fix it :)
  6. That'd be cool! Let me know if you figure it out, as it'd be handy to have the state detection
  7. No problem! Better to ask than to struggle :)
  8. What position have you got the switch in? It should be in position 3 to enter arming mode (i.e. the switch position closest to the USB input itself). If you've left it switched on one of the payloads, no LEDs will come on after the initial boot sequence, if I'm correct.
  9. Changing the switch position doesn't currently restart it / execute the payload associated with the new switch position.
  10. Yup, that's by design. I believe the logic being that the Powershell command needs to know the path that it is executing the cmd file from, so it finds the drive letter of the storage with the name "BashBunny", and then appends d.cmd to it (I think it was d.cmd anyway... it's whichever one kick starts it all). If it didn't copy the files into the root, then it may make it more difficult to know where the files are, due to it being potentially in two different locations (i.e. switch1 or switch2). I might see if it's possible to run it all within a switch folder instead of moving them, but
  11. I just gave the USB-exf payload a try on Windows 10, and it worked OK for me. I tried with varying cases on the extensions too (i.e. .pdf and .PDF) and worked OK. Which xcopy command do you have uncommented in e.cmd? I currently have: REM xcopy /C /Q /G /Y /E %USERPROFILE%\Documents\*.pdf %dst% >>nul REM Same as above but does not create empty directories xcopy /C /Q /G /Y /S %USERPROFILE%\Documents\*.JPG %dst% >>nul ) (Changed extension to JPG for testing purposes) According to the comments in the script though, it shouldn't create any empty directories
  12. I can confirm I also ran into the bug with the tools_installer payload, caused by the line endings. Removed them and tested with a clean slate (i.e. empty /pentest/) and it worked fine via one of the switches. I've opened up a pull request to merge in the file without line endings here, if anyone wants to grab a copy of the clean file: https://github.com/hak5/bashbunny-payloads/pull/12
×
×
  • Create New...