dark_pyrro

You probably got some input on Discord about it all

It seems to be rather non logic that it's the data line being faulty if the keyboard succeeds in passing through keystrokes when the Croc sits in line between the PC and the keyboard if it's not covered by warranty any longer, it's always possible to crack it open (which will void warranty) and check the soldering to verify if any cable isn't connected to the PCB properly (or, solder a new cable and USB connector to the PCB to eliminate any broken cable inside the "pigtail") to get an IP to ssh into, you need to configure the Croc to connect as a client to some WiFi network (or create a payload using a network attackmode), but since you can't get it into arming mode, you can't reach the config file or payload file on the udisk, try (as I said in the previous post) to connect to the Croc using serial instead when it is assumed to be in arming mode (even if it fails to mount as a storage device to the PC it's connected to) if you've had the Croc for a while, I doubt that it would be covered by warranty, but you could always try to submit a support ticket and ask

Tried different USB ports? Different computers? Tried to serial into the Croc when in arming mode?

What firmware did it have before the factory reset? It's there because the udisk is left untouched in large aspects on a factory reset. There's of course also a possibility that the factory reset wasn't successful. In what way does this show? Isn't it entering arming mode straight away? Does it enter arming mode after a while (like after 1 minute roughly)? Is Cloud C2 configured on the Croc?

What payload(s) are you using, and how did you encode/compile it? Using a 128 GB Micro SD card I rather overkill, but it depends on the use case.

How's that going to help fixing it?

The only thing I can think of is that the hardware switch is faulty. Otherwise, that shouldn't be an issue at all if all steps are executed properly. I don't think it is faulty though because it should blink blue in arming mode as well, not green. To test the hardware switch, boot the Bunny in arming mode and serial into it Safely unmount the Bunny storage from the target computer (i.e. the computer that the Bunny is attached to), but do not physically remove it from the computer In the serial terminal, run: udisk mount cd /root/udisk/payloads/extensions source ./get.sh GET SWITCH_POSITION && echo $SWITCH_POSITION it should return "switch3" flip the hardware switch of the Bunny to the middle position (with the Bunny still plugged in to the computer) and run the same command again it should return "switch2" flip the hardware switch of the Bunny to the position that is most far from the USB connector (with the Bunny still plugged in to the computer) and run the same command again it should return "switch1" then run cd udisk unmount

More details needed. What modules are you trying to install using the web UI? What packages are you trying to install manually? What exact errors/feedback do you get?

Define "not working". In what way isn't that payload working? What are you expecting to happen, and what does actually happen? Not possible to serial into the Bunny using that payload? Not showing up as a storage device on the target device? What other payloads have you tried? Are you using a Micro SD card?

Not really sure why all that text was needed to ask that question, but, anyway... What is the definition of "secure" in this case? Non recoverable? If that is the definition, then no. Although it depends. Using some kind of file recovery software will most likely find the inject.bin file and be able to restore it. However, after successfully restoring the file comes the next thing, trying to "reverse engineer" the inject.bin file to readable plain text code which probably will be a challenge for most people.

The Croc has wireless built-in, but not for the purpose you're asking. The Croc needs to sit physically in-line between the PC and the keyboard to capture keystrokes.

It will execute the payload at every boot, so nothing strange about that. If you want to stop it from running the payload, you have to replace the payload with something else. Or, as you say, press the button at boot to enter arming mode.

Post Bunny related questions in the Bunny section of the forums. Also read the documentation, and be more specific about what you are trying and in what way it fails.

Or /root Not sure if it has changed in newer firmwares. On my Mark VII, I have the PineAP logs in /root/log.db though (and it's quite recently reset).

Did you check /tmp ?

That would be a way of doing it. At least try. Of course, there are always a bunch of "it depends" in all of this since every network isn't set up the same way. Most guest networks (or such) should work using this kind of method though. DNS servers might be needed to be tweaked in some cases, but that will be obvious when things aren't working when it comes to resolving domain names. Another way (a bit more steps though) would be to connect to the network using a device and register it on the guest network, then just use the MAC address of the registered device and set it as the MAC address of the wlan2 interface of the Pineapple.

It's possible (on most networks), so no real need for a feature request, but I would really not suggest using the Pineapple as a travel router. It's not the intended use case for it. But, if you are willing to accept any downsides you might experience (such as lack of network speed), it's nothing stopping you from using it that way.

When it comes to Hak5 products, I would most likely say no in this specific case. These kinds of scenarios almost always haven't got a quick and simple answer. One have to deep dive into the setup of the specific environment and look for possible ways that might be the result of such recon. It's also a good thing to let someone that knows these things do the work, and not try yourself if you don't have the knowledge needed. In worst case it will make the already bad scenario even more bad. Hire someone from a reliable company to do it instead. Another reason to why these kinds of questions perhaps don't get full answers is that it can be "malicious", i.e. none of the said is true (fake story/scenario) and someone just want tips on how to illegally access an environment they aren't allowed to access. The "lessons learned" in this case is that things happen, and however tragic they are, processes needs to be in place that stops these kinds of situations to appear. A single admin shouldn't be the only one in control of credentials, and they should for sure not store it on their personal devices.

If you have the Pro version of C2 and can't get access to the web UI features of the Pineapple, I'd suggest submitting a support ticket.

Post Pineapple related question in the Pineapple section of the forums (As the very first/pinned thread in this forum section says)

It's an implant that is supposed to sit in-line between a physical keyboard and a computer (or any other type of device that uses a USB keyboard that is "compatible" with the features that the Croc offers). It has WiFi, but acts as a client on the network it is connected to. It's not an AP (it can be tweaked to host one, but it's not how it was intended to be used though). If you find a general way of obtaining iPhone credentials over a network, then you could work on that use case and see if you are lucky, but I wouldn't hold my breath waiting for success.

If there is a way to exploit iPhones that way over a network, it might work. The Pineapple alone won't do the job getting screen lock information.

In what way are you starting C2? Manually, or as a service? Starting it manually in the terminal makes the process terminate when the terminal terminates. If so, you need to set it up as a service to keep it running even when you have no terminal active.

lol...