dark_pyrro

I should add to what I said that the Ducky doesn't "make you admin" because of some magic being used. It does what a keyboard does, nothing else (and a storage device if that mode is used). Just to make that clear.

Well, perhaps start by looking at some of the payloads on GitHub that "elevates" the current user to admin (assuming it has admin permissions to start with) and execute from a PowerShell window.

Yes, but just saying you haven't had any luck doesn't add much context to it all. So, the question remains: Any payload code that you have actually tried? What does that payload code look like?

What is the target OS? What have you tried this far?

I have no idea what a "sautr" is, but you probably have a gen2 Ducky if you just got it and there shouldn't be anything blocking the Micro SD card slot on the gen1 Ducky in the way that the USB-C connector mounting blocks the Micro SD card slot on the gen2. Bringing an 11 year old thread to life isn't most likely relevant in this case either.

Just go to https://payloadstudio.hak5.org/community/

I bet you're not going to get any help with that

The best way is most often related to why you want stronger signal and more range. What's the use case? And, the best way to get questions answered about the MK7 is to post them in the MK7 section of the forums, not in the section for the Mark IV.

What product was detecting it as malware and did it provide any information of why it was detecting it? The text below is from a quite recent post by the Hak5 head dev of Cloud C2 "Question: "C2 cloud download from hak5 says it has malware" Answer: **TLDR; its a false positive. CloudC2 contains no malware nor anything malicious. ** This is an unfortunately (and ironically) a side affect of providing our software in an *easily accessible zip for all architectures*. This arbitrary determination by random AV scanners is unfortunate and **nearly impossible to combat.** AV detection is a game of "if my AV detects it and yours doesn't, mine is better" so even false positives spread like wildfire. Understandably because in the case something is actually malicious this protects more users quicker (something we can all appreciate). So what nuance are these AV companies missing in their determination of Cloud C2? Architecturally Cloud C2 is designed to** only communicate with Hak5 devices**; there is no way to even abuse Cloud C2 to provide access to even the host its running on. The executables don't even communicate with the host machine they run on -- this is both by design and for your privacy and security; *Cloud C2 is effectively a sandbox*. We expressly provide the sha256sum of the archive, and within the archive a list of sha256sums of each individual binary so that you can be sure they haven't been intercepted or tampered with. Each binary is built and tested by us in house from the same codebase and then provided to the user via our own hand built infrastructure so that you can be sure no one is able to alter the software nor track you. **In even more detail:** The combination of features Cloud C2 provides, from a *blindly heuristic perspective*, has just fooled many scanners into** false positive**; looking to naive data models that it "could be used maliciously" due to the fact that it: - requires a token and a license key to access; providing security and ensuring you're the only one who can complete the setup process - contains a self contained web server that can communicate in a custom protocol scanners have never heard of and don't understand (expressly so that your Hak5 devices are secure when using Cloud C2) - supports https and uses aes256 to communicate with Hak5 devices, making traffic uninspectable - contains a ssh server so you can remotely shell in (only) to your registered devices with a single click - supports one click OTA updates as a self updating binary - contains a cross platform compatible database architecture - contains a fully built-in web ui (which would appear as an embedded file system) - supports user accounts with fully configurable role based access control for your data security - supports full audit level internal logging of requests made to your server and actions taken by your server users **All with zero external dependencies packaged into a single executable.** The **only communication Cloud C2 server makes**: - directly with your Hak5 devices you've explicitly registered with your server, - to validate the license and only the license information."

Just send an email to the address from which the order confirmation was sent. It has worked for me when I've had reasons to have questions about my orders (which hasn't been many btw over the years). I guess you are the same one that posted on Discord about that error. The USB (onboard) hub is probably broken which doesn't make it possible to access the USB mounted radios (and when saying USB, I don't refer to any of the physical USB ports on the Pineapple, but a USB hub that you can't use like a regular hub since it's onboard connecting the onboard 7601 based radios that you seem to have issues with). Also, make sure that the Pineapple gets enough power. I seem to remember that there has been situations when an underpowered Pineapple has shown such error. Use a power source that is guaranteed to be able to deliver 2A and that the cable used is rated for at least 2A as well (using the cable that came with the Pineapple is a good start). If these requirements have been met, and it still show those errors, then it's likely that the mentioned USB hub is bad.

Nice...

wlan2 represents the WiFi client interface of the Pineapple, so I can't see why that would directly be involved in the use of the evil rogue AP.

There is a "conflict" here. Combining the two (plugging the SJC directly to the router, and having the SJC in arming mode) should lead to issues since the Shark will "be the network" in arming mode (using the IP address of 172.16.24.1) and reaching that address shouldn't really be possible since/if the router presents a totally different network and expects networking clients to connect to it. That's also why I'm a bit surprised you are even able to ping it or be able to get something in return when trying to ssh into it (although it throws back an error). To use the SJC as a client and plugging it into a router expecting it to get network (and internet) access, I would instead create a payload that would set the SJC in "NETMODE DHCP_CLIENT" at boot and also start the ssh daemon. Then find the IP address that the Shark has received on the LAN and ssh into it. This will not work for different reasons. One is that your MacBook most likely don't have a DHCP service running that is able to hand out a DHCP lease to the SJC. You will also have additional issues since you most likely need to configure both the Shark and the Mac to let the Shark have internet access via the Mac.

That can't be too difficult to do a Google search on. Especially since "John" is also mentioned in the payload readme/instructions plus the fact that the GitHub repo is linked in the instructions. So... JtR stands for "John the Ripper", it's a tool. https://github.com/openwall/john https://en.wikipedia.org/wiki/John_the_Ripper https://www.openwall.com/john/ You haven't included any commands in the post, but I guess that you are referring to the commands in the payload instructions. They should be executed on the Bunny itself (when it has been configured to be able to reach the internet). You will most likely run into a bunch of errors while running the apt commands since Jessie is EOL and the upstream package repos aren't maintained anymore. The payload itself is interesting as a concept, but nothing I would use that much since it's rather limited in the way that it is only able to try a limited amount of possible passwords. I would go with QuickCreds/Responder instead and do any "password restoring" on something more powerful than the Bunny. The Responder version that is used in the payload is also older than needed.

Pro license of PayloadStudio is not included if you don't buy the "Pro" or "Elite" bundle when you buy the Ducky, which is possible to read all about on the shop page https://shop.hak5.org/collections/best-selling/products/usb-rubber-ducky It's possible to buy it separately as well https://shop.hak5.org/products/payload-studio-pro No, it's not necessary. You can use the community version for free (which is as cheap as it gets) as stated in the official documentation https://docs.hak5.org/payload-studio

OK, keep it the Nano section then, you will have the best chances of getting the most relevant answers in the case it's device specific. I haven't experienced it though over the years using the Kleo portals, not with the Mark VII or the Nano.

Is this the same use case as you've already posted about (twice) in the Nano section of the forums, or are you actually experiencing this on both the Mark VII and the Nano?

Did you set the 5 GHz adapter as the recon interface after the firmware upgrade?

The Nano is EOL so there will be no official fixes (and no already existing ones available that I've heard of over the years). You have to try to figure that out yourself if you necessarily need to connect it to a WPA3 enabled AP. OpenWrt 19.07 should support WPA3 though, but you probably need to tweak it to get it working. You will probably run into issues trying to install packages needed. Going down that rabbit hole might have negative effects on Pineapple features. My guess is that it's easier to use a WPA2 AP rather than to try to get WPA3-sta working on the Nano.

and is quite contradictory if the Nano gets an address, but doesn't show up as connected on the phone. Did you try connecting to some other AP? What USB adapter is it? Seems to be something based on RT2870 or similar. What's the output of lsusb and ifconfig and/or ip a ? Also the content of /etc/config/wireless

What error(s) did you get? Are you inserting the extensions in the proper way? I.e. is the code of each extension actually inserted in the payload? You can't just write it in the way you posted it. You have to make sure that there's actual code added when "calling"/inserting the extensions. (Also assuming you are using Payload Studio)

Yes, it's because Jessie is EOL. You could try to tweak the apt sources, but you will likely still have issues and it will get worse as time passes. There is an extended support source that is possible to use, but it's not Debian official and doesn't contain all the packages that you can find in a normal and supported Debian release.

Good that you got it solved. But you must have used another way other than the one you described in your post because that shouldn't be possible to get working.

No real course that I know of, at least not in-depth. The documentation covers the most that is Pineapple specific, some videos are available as well on YouTube. The majority of the rest that is needed to use the Pineapple is really about knowing computing and networking basics, and that kind of courses are there a lot of.

That's not the same thing as using apt (or serial either). Installing deb files using the "tools feature" is something else. https://docs.hak5.org/bash-bunny/getting-started/installing-additional-tools