Darren Kitchen

Try adding the MAN_ and SN_ parameters to your ATTACKMODE. You probably also need to add another mode in addition to just HID because simply HID by itself (or any one attack mode for that matter) will enumerate as a single-interface device rather than a multi-interface "composite" device, which is what the target is expecting. See https://docs.microsoft.com/en-us/windows-hardware/drivers/install/standard-usb-identifiers

@lartschthank you for the invaluable feedback, bug report, and fix. We're investigating this issue further and testing the patch you've provided as we continue work on the next firmware release.

Great feature request -- we've added it to the roadmap.

As @Bitwisesaid it's typically done with pip. You can share your computers Internet connection with the Bash Bunny and install all sorts of software with apt and the like -- here's a tutorial: https://docs.hak5.org/hc/en-us/sections/360002204213-Internet-Connectivity

Ok -- I'll go first 🙂 https://github.com/hak5/bashbunny-payloads/tree/master/payloads/library https://forums.hak5.org/forum/93-payloads/ ^_^

When you connect the Bash Bunny to your computer in arming mode, what LED pattern do you get -- and does it enumerate as either USB Mass Storage, Serial, or both?

A few key points to note when using a MicroSD card with the Bash Bunny Mark II: Arming Mode Payloads are executed from internal storage only. If a MicroSD card is present at boot in arming mode, it will be passed through to the host. To load payloads, boot the Bash Bunny without a MicroSD card present. Payload Modes If the STORAGE ATTACKMODE is active, the udisk will be presented to the target as a mass storage device. In the case that a MicroSD card is present, the udisk presented to the target will be the MicroSD card In the case that a MicroSD card is not present, the udisk presented to the target will be the internal udisk partition. By default the udisk is not mounted on the Bash Bunny regardless of the ATTACKMODE specified. To mount the udisk from the perspective of the Bash Bunny, issue the command `udisk mount`. Mounting Considerations The udisk partition — whether internal or MicroSD — can only be mounted on one device at a time. By default in all switch positions the udisk is not mounted on the host (the Bash Bunny itself). The /root/udisk directory will appear blank unless `udisk mount` has been executed. Writing to /root/udisk when unmounted will have no effect on the actual udisk partition. If both ATTACKMODE STORAGE and `udisk mount` are used — unexpected behavior may occur as the partition cannot be handled by both the target and host simultaneously. Formatting Considerations The MicroSD card should be partitioned with a single partition formatted with a filesystem appropriate to the target e.g. for Windows targets: FAT32, ExFAT, NTFS e.g. for Mac targets: FAT32, ExFAT, APFS e.g. for Linux targets: FAT32, ExFAT, EXT While the target may support various filesystems, the host (Bash Bunny) currently only supports EXT and FAT32. Additional filesystems (ExFAT) may be included in future firmware versions.

I just wanted to update the thread to point out that the Bash Bunny documentation at https://docs.hak5.org applies to both the original and Mark II devices. Articles have been added specifically for the new functionality of the Mark II. The reset procedure has not changed from the original. We're working with @Driftwood8891to determine what's at fault here as there are no obvious signs from the payload executed.

I should have clarified this earlier. I've written up an article to help clear this up. https://shop.hak5.org/blogs/bash-bunny/remote-triggers-for-the-bash-bunny-mark-ii The bottom section on how it works explains the function of the extension.

The product, both software and hardware, are done. We have units on our desks. Unfortunately, these are the only units we've been able to make as of yet. The component vendors aren't giving us clear timelines on delivery. Chips that used to have 4-8 week lead times are now "2023?". It's put us in a difficult position, so we are exploring all of the avenues at our disposal to release the Enterprise model ASAP. I understand this is frustrating, and I'll do my best to make updates & communicate as we navigate this industry wide chip shortage situation. Thanks in advance for your patience and understanding.

What module in particular were you looking for?

I can see you're disappointed. I want to understand your frustration so we can do better. I put a lot into this product and feel that it's the best WiFi Pineapple yet -- both in terms of the hardware and software, and want the experience to be the best it can. I'll see to addressing your concerns: - Packet injection does indeed work on all 3 interfaces. You can test this with the aireplay-ng -9 command. - Gathering WPA2 handshakes is a passive process and does not require packet injection. Handshake capture does indeed work. - We have a highly documented module API and went as far as to commission modules for launch by one of the communities best developers. If there is a specific module you want, please let us know and we will put resources behind that. - The support for this device has not changed from the last generations of WiFi Pineapple, and you will find us responsive and helpful on the forums, in our Discord, and if you reach out to open a ticket. - I believe the videos I've published should get you started with a good understanding of the basics. Otherwise, I'm confident that the user interface is intuitive enough to figure out -- but if there is a specific concern you have please share it, maybe it'll make for a good video topic. - Greed? We're make *less* on each WiFi Pineapple generation than the one before because we *increase* the hardware capabilities, not to mention the non-recoverable engineering and software development costs. Over 7 generations now, with each new version, we've added physical radios, increased the CPU power, increased the RAM, increased the storage, refined the UI -- and we've never increased the price. In short, you get out what you put in. Which is to say that if you constructively bring specific criticism it may be addressed thoughtfully, and you will find us very receptive to making the product and your experience with it better. But broad, emotional, "pretty useless" strokes don't lend to addressing your concerns.

Initial Setup The OTA installation from the stager (initial setup firmware) does not support hidden and open WiFi networks. It only supports WPA WiFi networks. This is addressed in a forthcoming update. WiFi Client Mode This is a known issue related to some WiFi networks on an old firmware (version 1.0.0) which has been solved on subsequent releases. In firmware 1.0.0 the WiFi Client Mode settings were not automatically saved. There was a save button for if you wished to manually save the profile, however we learned that many people were not noticing the save button. On firmware releases after 1.0.0 the WiFi profile is saved automatically. This bug in the old firmware 1.0.0 was shown when no networks were found and was solved in version 1.0.1 onwards. PineAP The Active Mode in PineAP will automatically populate the SSID Pool. If you don't want this feature enabled, you can use Advanced Mode and uncheck the Capture SSIDs to Pool box. There was a bug in the old version 1.0.0 where clearing the SSID Pool did not work correctly, which was addressed in a subsequent firmware update. Also, it should be noted that some devices (I can speak from experience on older Android phones) will cache the ESSID from a single BSSID and incorrectly report the network name in the UI. Changing the BSSID (MAC Address) will force the client device to update. If you run into this, open the terminal (icon on top-right) and run `logread` -- you will see the association attempts which will include insights on what's happening. Without seeing those logs, I can only speculate as to what's happening between the WiFi Pineapple and the client in question here. Recon Recon will populate clients associated with access points when data is seen being transmitted between both nodes. The duration of the recon scan will determine how much data is seen, as the dedicated monitor radio will channel hop to see the full 2.4 GHz spectrum. I hope this gives you some insight on these particular issues. Thank you for the bug reports and I am happy to say all of these issues had been addressed. It's posts like these, and the discussions on Discord -- both of which we monitor -- that help us make the WiFi Pineapple better with each release, so thank you for contributing.

I cannot speak to the kbeflo project you reference as I do not have experience with it - however if you are referencing the Evil Portal module from the WiFi Pineapple repository, I can say that exfiltrating loot from that module to the Cloud C2 server is the same as any other file. Example: C2EXFIL STRING /path/to/log/file payload-name *payload-name is option *STRING indicates that the file is ASCII and may be viewed in the browser. Omit for binaries.

If you run the `date` command on both your WiFi Pineapple and the server running Cloud C2 - are they the same? You also said that you have your WiFi Pineapple connected both to your computer and your LAN via WiFi, yet you are not providing the WiFi Pineapple with Internet access from the computer. Is this computer connected to the WiFi Pineapple via USB-C also the Cloud C2 server? If the WiFi Pineapple disconnects from the Cloud C2 server, does it reconnect after a few minutes? What do the server logs on the Cloud C2 server show after the WiFi Pineapple disconnects? After the WiFi Pineapple disconnects from the Cloud C2 server, has the date changed, and can it still ping the server running Cloud C2?