[SWITCH 1 adb usb | adb tcpip 5555 payload build help]

1 hour ago, D14b0l1c said:

When you ran your code were you able to execute adb shell commands like "adb shell dumpsys -l"?

I added adb shell dumpsys battery > /root/adb_batt.log to my previously posted payload code and it worked as expected.

[SWITCH 1 adb usb | adb tcpip 5555 payload build help]

Using "adb usb" on the Bunny will probably not work since the Bunny isn't acting as a USB host (? - not 100% verified, but likely). The Bunny is just using USB as a hardware interface for the different modes it can emulate (HID, STORAGE, SERIAL, *NETWORK...) So, it might be easy to try to be "logic" and think "hey, the Bunny has a USB port, therefore it's USB in all ways and forms". But that might not be fully true, it's most likely a USB device (with no host capabilities) at best. This is a possible reason to why "adb usb" works on a device that acts as a USB host (for example a computer), but not on the Bunny. Using the network based approach to connecting using adb (like my payload example does) would be the path I would continue on. Especially since "adb usb" doesn't seem to work, and the network alternative does (at least when I try it).

7 hours ago, D14b0l1c said:

The below is what bunny will look like if the bunny and phone are not seeing each other. 

login as: root
root@172.16.64.1's password:
           _____  _____  _____  _____     _____  _____  _____  _____  __ __
 (\___/)  | __  ||  _  ||   __||  |  |   | __  ||  |  ||   | ||   | ||  |  |
 (='.'=)  | __ -||     ||__   ||     |   | __ -||  |  || | | || | | ||_   _|
 (")_(")  |_____||__|__||_____||__|__|   |_____||_____||_|___||_|___|  |_|
 Bash Bunny by Hak5     USB Attack/Automation Platform

Last login: Wed Feb 28 16:29:06 2024 from 172.16.64.64
root@bunny:~# adb usb
error: no devices/emulators found
root@bunny:~# adb devices
List of devices attached

How did you execute these commands if your Bunny was connected to the phone? From the phone itself via serial or ssh?

[SWITCH 1 adb usb | adb tcpip 5555 payload build help]

I temporarily switched over to the Key Croc since it makes it easier to develop/test payloads instead of blindly run things using the Bunny with the help of LEDs, log files, etc.

Got it to work in the Croc and then went back to the Bunny (used a Mk1 Bunny, but that won't make any difference compared to using a Mk2 one).

This is the payload I used. The payload can for sure be a bit more "pretty" (while loop to wait for target IP address, etc.) but it works for a PoC scenario.
Getting the target IP can instead be made in the more "usual" way (i.e. using GET TARGET_IP)

ATTACKMODE ECM_ETHERNET

sleep 5

TARGET_IP=$(cat /var/lib/dhcp/dhcpd.leases | grep ^lease | awk '{ print $2 }' | sort | uniq)

/usr/bin/adb tcpip 5555
sleep 1
/usr/bin/adb connect ${TARGET_IP}
LED FINISH

 

[SWITCH 1 adb usb | adb tcpip 5555 payload build help]

I'm rather skeptic when it comes to the use of GET TARGET_IP before issuing ATTACKMODE ECM_ETHERNET. I can't see how the Bunny would be able to get the target IP before the Bunny is in a mode allowing it to act as an Ethernet "device" (and make the target connect and obtain a DHCP lease from the Bunny).

[SWITCH 1 adb usb | adb tcpip 5555 payload build help]

No real need to use any separate Bash script file since it's possible to run Bash in the payload.txt file (it's treated as a Bash file itself by bunny_framework).

[New to cloud c2]

35 minutes ago, hunter786 said:

do I need the Pineapple before I can start the setup process?

yes, when it comes to the Pineapple itself

however, not sure what you mean when saying

35 minutes ago, hunter786 said:

want to start the installation process

"installation process" of the Pineapple or Cloud C2? Assuming Cloud C2 because of the choice of where to post the question.

36 minutes ago, hunter786 said:

what is the easiest way to setup the community server? 

By starting to read the documentation and make a decision where you want to run it

https://docs.hak5.org/cloud-c2/

37 minutes ago, hunter786 said:

I have read through some of these posts and see many people are experiencing problems.

Most "problems" you may have read about are probably related to "first-week on the job challenges". It's super easy to set up and run if you haven't got any very specific needs.

[Cloudc2.service dropped]

Despite the messages you get when checking the service status, is the Could C2 server working? I.e. can you access the web UI? (Excluding the fact that your Pineapple might not connect successfully).

[mk7 shared internet connection]

Guess you have to provide more information about your computer setup when it comes to networking to be able to troubleshoot. It seems as if it's the use of ip addr add that throws back the error. What's the output of ip a on the computer to which the Pineapple is connected (without running the wp7.sh script or having the Pineapple connected to start with)?

[Using the SD card with the Bash Bunny MKII]

6 hours ago, Sphett said:

I tried to set it on the Windows format tool and the MiniTool Partition Wizard. Is there a way to name it on the root of the bash bunny?

Why not just try to plug the Bunny into a Windows machine in arming mode or some payload containing ATTACKMODE STORAGE (or use a Micro SD card reader) and then change the label using the standard OS features (i.e. right click the drive letter in Explorer and change the label).

6 hours ago, Sphett said:

Which line should I set it on in order to get it to save to the Micro SD card?

You shouldn't need to edit any line. The payload should take care of it if everything is set up correctly.

This isn't actually about the Bunny, it's more related to understand scripting basics.

However...

It's the payload.txt file that kicks it all off and it's the PowerShell line that initially identifies which drive letter the Bunny has on the target system
RUN WIN powershell ".((gwmi win32_volume -f 'label=''BashBunny''').Name+'payloads\\$SWITCH_POSITION\z.cmd')"
more exact
(gwmi win32_volume -f 'label=''BashBunny''').Name

For the sake of this "discussion"; let us assume that the drive letter of the Bunny is "D:" and $SWITCH_POSITION is "switch1"

Apart from identifying the current drive letter of the Bunny, the PowerShell line also starts the z.cmd file (located in the same switch directory as the payload.txt file)

The z.cmd file just "obfuscates" and "silently" runs the next command file; x.cmd (also located in the same switch directory as the payload.txt file)

An important thing (at least for the understanding of the payload) is the occurrence of "%~dp0" since it's a representation of the path from where the z.cmd file was executed
In this case %~dp0 will be the same thing as D:\payloads\switch1

So the line in z.cmd that says
cscript %~dp0\i.vbs %~dp0\x.cmd
actually says
cscript D:\payloads\switch1\i.vbs D:\payloads\switch1\x.cmd

So, moving further in the execution flow, x.cmd is started

In x.cmd, the following line is vital to understand how the Bunny is "addressed" using "%~dp0"
set dst=%~dp0\..\..\loot\USB_Exfiltration\%COMPUTERNAME%_%date:~-4,4%%date:~-10,2%%date:~7,2%_%time:~-11,2%%time:~-8,2%%time:~-5,2%

First thing to understand is probably why "\..\.." is used. Again, this is because of the path that "%~dp0" represents.
"%~dp0" is still equal to D:\payloads\switch1 in this example
The question now is; "Where is the "loot" directory of the Bunny normally located?"
Answer: In the root of the udisk, i.e. D:\ in this case
So... the script is "positioned" in D:\payloads\switch1
How do you position yourself in D:\loot ?
By addressing it using "\..\.." which changes the position in the file system 2 steps up (to D:\) and the down into \loot (and so on)
However, dst is just a variable (or more of a constant since it's not changing throughout the script), but it's used further on in the script
So, the "dst" constant will be something like; D:\loot\USB_Exfiltration\ (plus the target computer name along with a date/time stamp; note that the date/time handling probably needs some tweaking if you're not using US style formatting of date and time)

All in all, you shouldn't need to add any specific drive letter representing the Bunny in the script. As said, the payload should take care of that if the label of the Bunny (internal storage or Micro SD card) is the same as the label defined in the payload file (i.e. "BashBunny" if not actively changed when setting the payload up).

[SWITCH 1 adb usb | adb tcpip 5555 payload build help]

9 minutes ago, D14b0l1c said:

ATTACKMODE ECM_ETHERNET
ATTACKMODE HID

Using ATTACKMODE this way will kill the network on the Bunny straight away and it will just work as a HID device for the rest of the payload.

If you want HID (keyboard) and network at the same time, you need to specify it on the same line, such as:

ATTACKMODE HID ECM_ETHERNET

From the docs: "ATTACKMODE is a DuckyScript command which specifies which devices to emulate. The ATTACKMODE command may be issued multiple times within a given payload. For example, a payload may begin by emulating Ethernet, then switch to emulating a keyboard and serial later based on a number of conditions."

https://docs.hak5.org/bash-bunny/writing-payloads/attackmode

I would really advise you to read the documentation instead of blindly executing commands. It will save you time.

15 minutes ago, D14b0l1c said:

adb usb
ENTER
adb tcpip 5555
ENTER

Not sure what you want ENTER to do here. It's not a DuckyScript command and it's not Bash.

[Cloudc2.service dropped]

Hmmm, ok, so... the content of the post doesn't sync with the topic anymore. Guess the first "issue" was resolved then.

In what way are you starting your C2 server? Using the -https parameter I guess, since it's a log message that related to TLS. Are you using a domain name along with the https parameter? From previous posts, it seems as if you do. (You might also try not posting IP addresses that are "live", but that's your choice if you want to display that kind of information or not).

Also, you've posted about something very similar recently in another thread. In that thread you posted that you got a solution. Didn't that solution work?

 

[Websocket Opend - Closed (OMG)]

Try asking in the O.MG related sections of the forums.

[SWITCH 1 adb usb | adb tcpip 5555 payload build help]

I'm asking because I need to get an understanding of what you want to happen when running the payload.

I can't see that the while loop would work in any way, partly because the payload code is executed on the Bunny. In this case the Bunny would wait for the Bunny (unless there's some storage device on the Android device that is labelled "BASHBUNNY" that is automatically mounted to the Bunny in some way). Another thing stopping such a scenario to even happen is that the Bunny is just running as a HID device based on the ATTACKMODE used. There is no storage functionality involved. But, I can't see that happen despite using the storage mode for the Bunny. To get that idea to work, the device to which the Bunny is connected has to identify itself to the Bunny in some way for the Bunny to know that it's ready for input.

1 hour ago, D14b0l1c said:

Save this as adbpayload.txt in switch1/payload?

Payloads should be named payload.txt specifically, nothing else (as per the documentation).

https://docs.hak5.org/bash-bunny/writing-payloads/payload-development-basics

[SWITCH 1 adb usb | adb tcpip 5555 payload build help]

What are you trying to accomplish with the while loop?

[SWITCH 1 adb usb | adb tcpip 5555 payload build help]

1 hour ago, D14b0l1c said:

After some additional research I was trying to attempt my first payload:

SWITCH 1/Payload
ATTACKMODE HID
LED SETUP
adb usb
adb tcpip 5555
LED FINISH

When I plug my phone into usb and run:
adb usb
adb tcpip

I connect via the below app, and I am able to run all my "adb shell" commands. I would like to be able to use the bash bunny payload, so I don't have to connect to a laptop.

Not sure how the app is relevant to it all. Makes me a bit confused. Isn't the goal to be able to use adb to control the phone from another device (in this case the Bunny instead of a laptop)? I would base the use case on "How am I doing all of this using a laptop?" since it's the laptop that you want to replace with the Bunny (I assume that you aren't running such kinds of apps on a laptop and I haven't investigated further into what it might do since the GitHub page wasn't in English and I don't have time to translate, etc.).

Regarding the payload code posted, I assume that it's not working since it's not in a format that the Bunny would fully understand and be able to execute. The lines that contains strings that the Bunny should type needs to start with QUACK STRING followed by a line with QUACK ENTER. I would probably add some delays as well.

[Using the SD card with the Bash Bunny MKII]

1 hour ago, Sphett said:

I tried to name it "BashBunny" but it stayed in all caps.

Where did you try to set it?

1 hour ago, Sphett said:

So for this line in simple-usb-extractor payload; How do I set it to the name of the Micro SDcard which is  "BASHBUNNY"?

You shouldn't set it on that line.

[MY pineapple wont show the login page]

When you factory reset, are you using the web interface or the DIP switches to reset it (probably the DIP switches since you can't reach the web UI)?

[Using the SD card with the Bash Bunny MKII]

My previous post is still valid to that question

Reading what the docs say about storage on the Mk2 Bunny kind of says it all

https://docs.hak5.org/bash-bunny/getting-started/considerations-for-mark-ii#storage

"If ATTACKMODE STORAGE is active:
- In the case that a MicroSD card is present, the MicroSD Card will be presented to the target
- In the case that a MicroSD card is not present, the internal udisk partition will be presented to the target."

So, as the quote above from the docs says; if you use ATTACKMODE STORAGE in a payload, the Bunny storage will be mounted to the target device. This will be true either if using the Bunny internal storage (without a Micro SD card inserted), or if using a Micro SD card. In other words, if you have a Micro SD card inserted into the Bunny and you are using ATTACKMODE STORAGE, then the Micro SD card will be mounted to the target as a "USB drive". This also makes it transparent in terms of how to script things in the payloads used (as long as the Micro SD card is labeled with the same name as the internal Bunny storage, i.e. "BashBunny").

Using the previously mentioned simple-usb-extractor payload, it shouldn't matter if you use the Bunny with the internal storage or a Micro SD card. The payload should work in both cases. If using the internal storage only (not any Micro SD card), it will exfiltrate things to the Bunny internal storage. If using a Micro SD card (labeled "BashBunny", or tweaking the payload to use whatever label the Micro SD card has), it will exfiltrate things to the Bunny Micro SD card.

 

[apt update && apt upgrade sources.list issues]

However, it's possible to "force" adb to be installed on the Bunny. Did the operations below and got adb to execute. Not sure if there are more things needed to be installed for specific adb functionality, but that will probably show in one way or the other when using it.

wget --no-check-certificate https://archive.debian.org/debian/pool/main/a/android-platform-system-core/android-liblog_7.0.0+r33-1_armhf.deb
dpkg -i android-liblog_7.0.0+r33-1_armhf.deb

wget --no-check-certificate https://archive.debian.org/debian/pool/main/a/android-platform-system-core/android-libbase_7.0.0+r33-1_armhf.deb
dpkg -i android-libbase_7.0.0+r33-1_armhf.deb

wget --no-check-certificate https://archive.debian.org/debian/pool/main/a/android-platform-system-core/android-libcutils_7.0.0+r33-1_armhf.deb
dpkg -i android-libcutils_7.0.0+r33-1_armhf.deb

wget --no-check-certificate https://archive.debian.org/debian/pool/main/a/android-platform-system-core/android-libadb_7.0.0+r33-1_armhf.deb
dpkg -i android-libadb_7.0.0+r33-1_armhf.deb

wget --no-check-certificate https://archive.debian.org/debian/pool/main/a/android-platform-system-core/adb_7.0.0+r33-1_armhf.deb
dpkg -i adb_7.0.0+r33-1_armhf.deb

 

[apt update && apt upgrade sources.list issues]

Just tried using Freexian ELTS on one of my Bunnies and it works. Sadly, it doesn't contain an install candidate for adb though.

[apt update && apt upgrade sources.list issues]

The situation when it comes to apt update or to apt install things on the Bunny will get worse for each day that passes. Jessie is EOL since long, and even if there has been (or perhaps still are) workarounds available, those workarounds will stop working as time goes by. There is a non official ELTS available for Jessie, but that doesn't cover the full scope of what Jessie once was. You could try the Freexian ELTS, but it's at your own risk. It might work to some extent, or it might not...

If successful, one thing that you shouldn't do is run apt upgrade (either using official channels or something else). It will risk messing the Bunny up. Just run apt update and then apt install what you need.

[Using the SD card with the Bash Bunny MKII]

exFAT should be possible to use from the target perspective, so that shouldn't be an issue. However, if it is to be accessed by the Bunny itself for some reason, exFAT won't be a possible option at this time.

[[Info] Tools]

Just now, Sphett said:

are the tools supposed to be in the root/udisk or outside the root folder?

If you're asking where the "tools" are installed, it's most often in /tools of the Bunny internal file system. But it all depends on what the deb package tells it to be located/unpacked.

[[Info] Tools]

From what I can see, there are 3 payloads in the GitHub library that are using gohttp as a tool requirement.

[[Info] Tools]

You have to check any payloads that you plan to use to see if GoHttp is required. Since you shouldn't run payloads "blindly", it will be obvious if it's required when you browse and learn the payload code for a specific payload. I haven't used it myself, it's easier to just run alternatives if needed (but it always depends on the use case what's relevant to use or not).