dark_pyrro

And here's some PoC code that runs an older Responder version (3.0.6.0), better late than never... https://codeberg.org/dark_pyrro/LAN-Turtle-1stGen-Quickcreds

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.