uploading payloads and extensions #646
Conversation
SHELL_TRIGGER: SHELL_TRIGGER is an extension which triggers commands/scripts on shell execution on target's system OR triggers commands/scripts when target executes terminal emulator.
keyboard_hangover is a powerful payload which randomly remaps target’s keyboard and and auto-triggers it.
malware_exec fetches malware hosted on Internet and executes it on targets system making it autorun on shell execution and persistent without root privileges.
mysql_dump payload exfiltrates MySQL history, which can be used to understand targets database schema.
network_surveillance payload exfiltrates network connections, routing tables, interface statistics, masquerade connections, and multicast memberships.
Simple yet Powerful payload which can be used to replace one command with another on target’s system. swap_jack gives your target ability to trigger backdoors for you.
drapl0n
changed the title
| # BROWSER_EXEC v1 by @drapl0n | ||
| # BROWSER_EXEC finds browser installed in target's system and searche for URL in it. | ||
| # Usage: BROWSER_EXEC <URL> | ||
|
|
There was a problem hiding this comment.
Please go and add a comment on your extensions specifying the target OS.
| Q DELAY 200 | ||
|
|
||
| # [Fetching BashBunny's block device] | ||
| Q STRING disk='$(lsblk -fs | grep BashBunny | awk '\'{print\ '$1'}\'\)'' |
There was a problem hiding this comment.
I would recommend using a variable assignment for the drive label as not everyone's configuration will have the default BashBunny drive label. This makes user configuration much easier.
You can do this by adding it to the top of your payload. For example with line:
DRIVE_LABEL="BashBunny"
Q STRING disk='$(lsblk -fs | grep '"$DRIVE_LABEL"' | awk '\''{print $1}'\)''
| # Attackmodes: HID. | ||
|
|
||
| LED SETUP | ||
| ATTACKMODE STORAGE |
There was a problem hiding this comment.
Your payload is doing keystroke injection, I would change this to ATTACKMODE HID STORAGE so the bash bunny can identify as both.
There was a problem hiding this comment.
Purely Destructive payloads will not be accepted. No, it's not "just a prank".
Subject to change. Please ensure any submissions meet the latest version of these standards before submitting a Pull Request.
I would change the focus of this payload to be program execution rather than "malware"
| Q DELAY 200 | ||
|
|
||
| # [Fetching BashBunny's block device] | ||
| Q STRING disk='$(lsblk -fs | grep BashBunny | awk '\'{print\ '$1'}\'\)'' |
There was a problem hiding this comment.
Similar to your other payload, I would recommend using a variable assignment for the drive label as not everyone's configuration will have the default BashBunny drive label. This makes user configuration much easier.
You can do this by adding it to the top of your payload. For example with line:
DRIVE_LABEL="BashBunny"
Q STRING disk='$(lsblk -fs | grep '"$DRIVE_LABEL"' | awk '\''{print $1}'\)''
| # Attackmodes: HID, STORAGE. | ||
|
|
||
| LED SETUP | ||
| ATTACKMODE STORAGE |
There was a problem hiding this comment.
Your payload is doing keystroke injection, I would change this to ATTACKMODE HID STORAGE so the bash bunny can identify as both.
| Q DELAY 200 | ||
|
|
||
| # [Fetching BashBunny's block device] | ||
| Q STRING disk='$(lsblk -fs | grep BashBunny | awk '\'{print\ '$1'}\'\)'' |
There was a problem hiding this comment.
Similar to your other payload, I would recommend using a variable assignment for the drive label as not everyone's configuration will have the default BashBunny drive label. This makes user configuration much easier.
You can do this by adding it to the top of your payload. For example with line:
DRIVE_LABEL="BashBunny"
Q STRING disk='$(lsblk -fs | grep '"$DRIVE_LABEL"' | awk '\''{print $1}'\)''
| Q DELAY 200 | ||
|
|
||
| # [Fetching BashBunny's block device] | ||
| Q STRING disk='$(lsblk -fs | grep BashBunny | awk '\'{print\ '$1'}\'\)'' |
There was a problem hiding this comment.
Similar to your other payload, I would recommend using a variable assignment for the drive label as not everyone's configuration will have the default BashBunny drive label. This makes user configuration much easier.
You can do this by adding it to the top of your payload. For example with line:
DRIVE_LABEL="BashBunny"
Q STRING disk='$(lsblk -fs | grep '"$DRIVE_LABEL"' | awk '\''{print $1}'\)''
| @@ -0,0 +1,7 @@ | |||
| #!/bin/sh | |||
| disk=$(lsblk -fs | grep BashBunny | awk '{print $1}') | |||
There was a problem hiding this comment.
Please add instructions to your readme to indicate to the user that if they aren't used the default drive label that it will need to be changed in the payload.sh script.
| Q DELAY 200 | ||
|
|
||
| # [Fetching BashBunny's block device] | ||
| Q STRING disk='$(lsblk -fs | grep BashBunny | awk '\'{print\ '$1'}\'\)'' |
There was a problem hiding this comment.
Similar to your other payload, I would recommend using a variable assignment for the drive label as not everyone's configuration will have the default BashBunny drive label. This makes user configuration much easier.
You can do this by adding it to the top of your payload. For example with line:
DRIVE_LABEL="BashBunny"
Q STRING disk='$(lsblk -fs | grep '"$DRIVE_LABEL"' | awk '\''{print $1}'\)''
No description provided.