After the successful exploitation, exploit module should have something to send in order to get a remote shell or any other kind of impact. This is where payloads come in action. HatSploit provides an extensive interface for payload development and supports all kinds of them:

• Shellcodes - These payloads are highly architecture dependent due to that they are written in pure assembly. HatSploit enables payload authors to store payloads in assembly code rather then publishing compiled shellcodes.
• Scripts - These payloads can be any script, from BASH, Python or PowerShell code to a single command.

All payloads are different and are created for different purposes, however HatSploit has a strict payload system to distinguish them. There are two types of payload:

• Stager - Payload that is sent first and the main purpose of which is to read the next (bigger) payload into memory and execute it.
• Staged - Payload that can be sent by itself or after the stager. This payload is flexible and can contain multiple ways it can be executed, while stager has only one.

Using payloads

To use a specific payload, you should first select the module that supports payload execution.

Let’s take exploit/linux/skybridge/100_110_code_execution module that exploits the built-in backdoor in several routers and attempts to gain code execution.

[hsf3]> search skybridge

Modules:

    Number    Category    Module                                                    Rank    Name
    0         exploit     exploit/linux/skybridge/100_110_code_execution            high    SkyBridge MB-A100/110 Remote Code Execution
    1         exploit     exploit/linux/skybridge/100_110_credentials_disclosure    high    SkyBridge MB-A100/110 Credentials Disclosure

[hsf3]> use 0
[*] Using default payload linux/armle/shell_reverse_tcp...
[hsf3: SkyBridge MB-A100/110 Remote Code Execution]> options

Module Options (exploit/linux/skybridge/100_110_code_execution):

    Option     Value                            Required    Description
    HOST                                        yes         SkyBridge host.
    LHOST      10.39.23.43                      yes         Local host.
    LPORT      8888                             yes         Local port.
    PAYLOAD    linux/armle/shell_reverse_tcp    yes         Payload to use.
    TIMEOUT    10                               no          Connection timeout.


Payload Options (linux/armle/shell_reverse_tcp):

    Option     Value          Required    Description
    ENCODER                   no          Encoder to use.
    RHOST      10.39.23.43    yes         Remote host.
    RPORT      8888           yes         Remote port.

As you can see, we already have a payload preconfigured for us to use on an exploited system. You can invoke info command to find more information about the effects of the module.

[hsf3: SkyBridge MB-A100/110 Remote Code Execution]> info

    Name: SkyBridge MB-A100/110 Remote Code Execution
  Module: exploit/linux/skybridge/100_110_code_execution
Platform: linux
    Rank: high

Authors:
  Ivan Nikolskiy (enty8080) - module developer

Description:
  SkyBridge MB-A100/110 firmware <= 4.2.0 has an Android Debug Bridge
  service exposed allowing attacker to execute arbitrary commands.
  Sessions generated by this module are weak due to that ADB sometimes
  fails to execute payload in background and when ADB session is
  closed all sessions are closed too. Session will stay alive as long
  as auto-interaction is turned on.

References:
  URL: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-23578
  URL: https://www.seiko-sol.co.jp/products/skybridge/skybridge_download/mb-a100/
  CVE: 2023-23578

Devices:
  SkyBridge MB-A100 - firmware <= 4.2.0
  SkyBridge MB-A110 - firmware <= 4.2.0

Stability:
  Module does not crash target

Reliability:
  Module spawns weak (unstable) session

Developing the payload

If you want to contribute and develop your own payload, you might find this guide useful - Writing Payloads