Jump to content

Fang_Shadow

Active Members
  • Posts

    35
  • Joined

  • Last visited

Posts posted by Fang_Shadow

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

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

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

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

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

  6. 6 hours ago, Sebkinne said:

    You also need to set the systemd kill mode to process instead or the default process group. 

    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.

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

  8. If it is failing to install automatically then you will need to install it manually through device manager, by chance is there an unknown section with a warning symbol next to any of the devices? If so then go to properties and update driver -> manual and select the bash bunny mass storage, it will auto select and install the inf file as driver info.

×
×
  • Create New...