Exploit vs Payload

From Embedded Lab Vienna for IoT & Security
Jump to navigation Jump to search

The terms "exploit" and "payload" have many different definitions, depending on what area of expertise is currently discussed. This article will explain the two terms within the context of IT Security and, more specifically, Penetration Testing with Metasploit.

Definitions

"exploit"

"exploit", which comes from the verb "to exploit" meaning "to make use of meanly or unfairly for one's own advantage" [1] generally refers to a piece of software, data or sequence of commands or instructions to take advantage of a bug or vulnerability in order to cause some sort of unintendet, unwanted or malicious behavior in a piece of software or hardware. Exploits are thus usually used to take over, gain access to or interfere with the operation of a system [2], when talking about computer security more generally.

In the context of penetration testing with Metasploit, the term "exploit" is more narrowly defined as "a sequence of commands that target a specific vulnerability found in a system or application to provide the attacker with access to the system" [3]. In other words, in the context of Metasploit, an "exploit" refers to any way to gain remote code execution (= "RCE") on a target system, and nothing more. Examples for exploits can be as simple as using ssh/telnet to log into a system using known (well-known or leaked) credentials and as complicated as leveraging multi-step zero-day vulnerabilities to gain RCE on a highly secured system.

"payload"

"payload", which comes from the noun of the same name meaning either "the load carried by a vehicle exclusive of what is necessary for its operation" (more relevant for computing in general) or "the destructive component carried by a missile or bomb" (more applicable to penetration testing) [4] in the context of computing generally refers to a piece of data that is the actual message or information that should be communicated, excluding all headers or other information required added by and/or required for the transmission method or protocol [5].

In Penetration Testing, the term "payload" refers to the piece of data or sequence of instructions that is transmitted to the target system and then executed there. To execute the payload, RCE has to be gained beforehand, which is the reason why payloads are designed to be used together with exploits in the Metasploit Framework. Common payloads include reverse shells (where the attacked system connects to an attacker controlled server with a shell session and this session is then reversed to gain access to the attacked system, hence the name "reverse shell"), "download and execute" payloads (which download a remote-hosted executable from an attacker-controlled server and then execute it, commonly installing malware like keyloggers, persistent shells, rootkits, adware, etc.), as well as the Metasploit-specific "Meterpreter" payload (a powerful type of reverse shell which comes with many useful tools for further working with a successfully attacked and exploited system) [6].

Definition summary

To summarize, "exploit" commonly refers to a malicious piece of software/data that abuses vulnerabilities to do something the owner of the attacked system did not intend the system to do, and is defined as a way to gain remote code execution by Metasploit and similar tools. The term "payload" is commonly defined as the actual data that is transmitted via some way excluding any headers or other transmission information, and is used in the context of Metasploit to describe the software or command that are executed on the target using the RCE gained by an exploit. Metasploit integrates the transmission of the payload into the exploit configuration.

Exploit Payload
Goal Gain RCE (Remote Code Execution), NOTHING MORE Execute Code on Machine where RCE was gained by Exploit
Examples ssh Login, using vulnerabilities,... Reverse shell, Persistent Entrypoint, ...

Simple Visualisation

To visualize the difference, a simple example is to use a ssh login using a known public key and a simple bash script as a payload. This example is working using only ssh and bash, and without requiring any additional tools like Metasploit, demonstrating how simple an exploit can be and that similar results can also be achieved using simple tools commonly installed on many devices.

  • The sample Exploit is a ssh login using a known public key. This satisfies the definition for Exploit, as all it does is provide the opportunity to run code on the target system (i.e. Remote Code execution)
  • The sample payload simply emits the current user it is run as, and places a file on the target machine as proof that it ran there.

Exploit Sample bash script:

ssh $1@$2 -p $3 "bash -s" -- < $4

Payload Sample bash script:

echo "I am $(whoami)!"
echo "This file was created using the payload!" > I-was-here.txt
echo "File planted. Good bye!"

Exploit development in Metasploit

The Metasploit framework is made up of a variety of different Modules, targeted at supporting as many different activities around the exploitation of vulnerabilities as possible, starting with scanning for vulnerabilities, the exploit itself and ending with post exploitation tasks like data exfiltration. [7]

Two of these module types are "exploit" and "payload", with the goals and functionality described above.

While it is possible to develop one's own Metasploit exploits, and in fact even encouraged by the team behind the Metasploit Framework, developing one's own payloads, also known as BYOP (="Bring Your Own Payload"), while possible, is not officially supported by Metasploit and not easy to integrate. Developing own payloads requires setting up the entire infrastructure (e.g. C2/Command and Control servers, transmission protocols (which sometimes have to be customized),...) and tools from scratch, while writing own exploits is vastly easier using existing integrations into the Metasploit Framework, which simplifies and standardizes many tasks required for exploits [8]. Compared to custom payloads, built-in payloads are very easy to use, and come with any tools that are needed like, for example, an all-batteries-included server implementation for the reverse shell payloads to connect to and establish the reverse shell.

Metasploit exploits (mostly written in Ruby, but Python is also possible, although not as well documented) can be directly integrated into Metasploit by simply placing them in a subfolder of `~/.msf4/modules/exploits`. These exploits will then be available from within Metasploit just like any built-in exploits. For example, if an exploit is placed as `~/.msf4/modules/exploits/demo/ssh_login.rb`, it will be displayed in Metasploit as an exploit with the name "demo/ssh_login.rb".

While it is difficult and very time consuming to develop own payloads, these custom payloads can be used together with Metasploit exploits using the following methods:

  • The `payload/generic/custom` is a built-in payload which can be provided with a file or url which is included in the payload. However, this both requires a custom payload (with all the infrastructure) and at the same time is very hard to troubleshoot, as an unsuccessful execution simply exits the attempt, without any feedback.
  • Multi-stage Payloads can download a custom payload as one of it's steps, but this also requires first developing the payload and infrastructure.
  • The Metasploit Framework does not just contain the main `msfconsole` tool, but also other tools like `msfvenom` which is used for encoding and manipulating payloads. Like the other options for developing custom payloads, this tool has a higher barrier for entry than the relatively simple `msfconsole` and it's pre-configured ready-to run exploits, payloads and other tools.

There is one alternative to writing a custom payload in some cases, for example when all that is needed is a custom tool to use once connected to the attacked system. In these cases, it can be feasable to instead develop a custom Meterpreter Module, which is then usable using the powerful built-in Meterpreter payloads and it is even possible to load custom Meterpreter modules after a session is already established, since Meterpreter Modules are executed on the attacker's machine and Meterpreter is responsible for resolving the commands using Metasploit features like Railgun (an integration for Windows Meterpreter that allows full control of the Windows API) [9]. This makes development easier, but also limits what a Meterpreter Module can do to what Meterpreter itself is able to do.

References