Jump to content

Search the Community

Showing results for tags 'attackmode'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Talk
    • Everything Else
    • Gaming
    • Questions
    • Business and Enterprise IT
    • Security
    • Hacks & Mods
    • Applications & Coding
    • Trading Post
  • Hak5 Gear
    • Hak5 Cloud C²
    • WiFi Pineapple Mark VII
    • USB Rubber Ducky
    • Bash Bunny
    • Key Croc
    • Packet Squirrel
    • Shark Jack
    • Signal Owl
    • LAN Turtle
    • Screen Crab
    • Plunder Bug
  • O.MG (Mischief Gadgets)
    • O.MG Cable
    • O.MG DemonSeed EDU
  • WiFi Pineapple (previous generations)
    • WiFi Pineapple TETRA
    • WiFi Pineapple NANO
    • WiFi Pineapple Mark V
    • WiFi Pineapple Mark IV
    • Pineapple Modules
    • WiFi Pineapples Mark I, II, III
  • Hak5 Shows
  • Community
    • Forums and Wiki
    • #Hak5
  • Projects
    • SDR - Software Defined Radio
    • Community Projects
    • Interceptor
    • USB Hacks
    • USB Multipass
    • Pandora Timeshifting

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start





Website URL







Enter a five letter word.

Found 8 results

  1. Hi Let's start with the scenario. Say you'd like to connect the Bash Bunny to another device that doesn't accept ACM. One such scenario is when connecting to mobile device like Android. These devices communicate through a protocol but only over a USB data connection. (Unless I'm misstaken) So none of the currently available attack modes support this. I'm sure there are more scenarios where this is applicable. And forcing other drivers to be loaded by the target would enlarge the possible attack surface. My questions are therefor if it is possible to add new attack modes? And if so, what steps are required to make this possible. Or if anyone have been able to connect to an Android device through USB. (Not by enabling ADB over ethernet/Wi-Fi, opening a port and issuing the command "adb connect". When connected correctly over USB issuing "adb devices" should list the target)
  2. I want the Bash Bunny to work reasonably well with Windows but not have the same identifiers it comes with. Can Hak5 recommend an alternative VID/PID or SN to use in an attack that disguises the Bash Bunny in a cromulent manner? I like the OS determination method represented in the WIN93 prank and other payloads. However, in a windows computer already set up with the Bash Bunny for Ethernet sharing, this does not work well. I also imagine it might not work well in a computer that is actually using the embiggened blue vendor products that you are spoofing instead of the Bash Bunny. I wonder if, during the development of the Bash Bunny, you had some VID/PID that worked sort of OK which I could spoof, thus having an alternative ethernet RNDIS device. This could be useful for other payloads too. I'd like to enhance the OS determination of the WIN93 prank to take another try where if not windows or linux, try an alt vid pid sn mix. I will experiment with this as well.
  3. Testing the BashBunny for use on a physical pentest/red team engagement but noticing a huge problem with using this device for a real world assessment. Mainly, on a Windows 7 x64 desktop, the initial driver install process took over 2 minutes to install. After initial drivers are installed, my payload initializes and finishes within 10 seconds which is great if only I didn't have to install the drivers first... What makes this issue even worse is that the BashBunny doesn't wait until the drivers have been installed before executing the payload which means you need to unplug/re-plug the device in after waiting 2 minutes to execute the payload. Ideally, it would be nice to build some code into the BashBunny to automatically detect when the drivers are installed and then run the payload. Has anyone had any issues with this and is there any way to improve the speed here? 2 minutes is wayyy to long to wait around at an unlocked workstation. I would be better off typing out the payload by hand if it meant only taking 20-30 seconds max.
  4. I am experiencing an issue with mounting the storage (/root/udisk). Anytime I run "mount -o sync /dev/nandf /root/udisk", the Bunny mounts udisk correctly, but does not stay mounted. Every time I reload the Bunny, udisk is not mounted. I even wrote a shell script that automatically runs this command at startup (I tried all three in the highest rates response and crontab to no avail), and udisk does not mount. It has been included in /usr/bin so that I can run it without having to navigate to that specific directory with the .sh file, and that works too. I tried running this script as part of a Bunny payload, and it still will not mount as part of a payload either. I can only get udisk to mount by SSH or a Serial Connection to the Bunny. I am using the latest version. The kernel version from "uname -r" is 3.4.39 if anyone needs to know that. Any ideas on what is going on? If you need any more information, let me know. Thanks in advance, -iHaveBlueHair
  5. Whenever I switch from ATTACKMODE HID STORAGE to ATTACKMODE RNDIS_ETHERNET, Windows 10 (1607) gives me a USB Device Not Recognized. It seems like the OS is rejecting it because the device that is was before is no longer there, and it it's like, hey, this wasn't there a second ago... I do get the USB device disconnects, and RNDIS_ETHERNET does work on this machine all by itself, but it seems that switching is the issue. Can anyone shed light on this? Device manager shows up as Unknown USB Device (Configuration Descriptor Request Failed).
  6. I just wanted to post about an error with the wiki. The part that shows how to put a VID and PID in ATTACKMODE commands is incorrect. The following line will not work. You have to include underscores like so
  7. I've been trying to setup the bunny to work with RNDIS_ETHERNET STORAGE Serial but without success. The combination of any two of those selections works as expected, but any ordered combination of those 3 fails to mount any one of the three devices on M$ Surface, Win10 10.0.14393 Using the Payload.txt below, after the 7 second boot cycle, the LED turns purple and stays purple for 113 seconds, after which the LED turns white, but no storage, serial, or network device is present. After the LED has turned white however, device manager appears to refresh every so often like it's trying to enumerate new devices, but none show up. I'm not finding any relevant event log entries. Are their any persistent logs available via arming mode serial? #!/bin/bash LED R B ATTACKMODE STORAGE SERIAL RNDIS_ETHERNET LED R G B
  8. I don't know if this is practical at all, but I think it'd be pretty cool to be able to flip the switch a series of times to access different payloads or render the bunny inactive/active. Depending on the types of signals you guys use. Does the bunny necessarily restart after you flip the switch or is there an internal kill bash that happens and it switches to execing the other payload? Haven't got mine yet so I don't know. If so, I could probably put conditional logic to hide or disable the scripts.
  • Create New...