###### tags: `fh` `AKITS`
# Metasploit/Meterpreter
[TOC]
## Introduction
This paper will present an overview of the payload meterpreter. Meterpreter itself is an post exploitation tool so to use it at all, a vulnerability in a system has to be exploited first. This is the reason why in the process of explaining Meterpreter, what is is how it works, what it is used for and most importantly how it is used, it is not possible to leave out the Metasploit framework. In the documentation of Meterpreter it is even stated that it was specifically developed to be used as part of meterpreter and today it is an essential part of the framework.
The first chapter will therefore give a quick overview over the basics of the Metasploit framework, while the second part delves deep into the Meterpreter Payload, includinge packet structure and packet flow. The last part will demonstrate Meterpreter with a practical example on an android device.
## Metasploit
Metasploit is an exploitation tool available for Windows and Linux and OS X. For educational purpouses it is widely used in virtual machines. The Linux distribution named Kali has Metasploit as part of its core set of programms. Thats why this operating system is often used when setting up virtual machines for testing and/or educational purpouses. It can be thought of as library of known exploits for computer systems. This means that so called 'day one' hacks are not available since they are either not discovered yet or not known well enough.
### Goals
The Metasploit framework is used as a tool to find weakpoints in a systems security and exploit them. This is done either with malicious intent which is illegal, or by ethical hackers. The latter ones are either contracted by the owner of the system directly or indirectly as a sort of bounty hunter. The directly contracted hackers act with the knowledge of the contractor on finding weakpoints so that they may be fixed and make the system more secure.
### Usage
As previously mentioned, the metasploit framework is usually used on the Linux distribution Kali-Linux, but it may also be used on windows or other platforms. So to use it, it first hast to be installed if Kali-Linux is not used. After that it is fairly simple to check if the installation was a success by opening the user interface. There are 3 options:
* command line interface or CLI for short
* graphical user interface or GUI for short
* a web interface

The first option is executed by opening a terminal, the command line on windows, or other similar interfaces if other platforms are used. On Linux type 'msfconsole', and under Windows open the msfgui interface and acces the console link from the menu in the window. Now the console should display an ASCII art logo, print the current version and current module count and afterwards drop to a 'msf?' prompt. From there on out the metasploit framework can be explored and used, idealy starting with the 'help' command to show which commands are currently available.
(Source:self-made)
To allow for an easier workflow the metsploit framework console was designed to recognize system commands. This allows to use common commands such as, chown, grep or cat to be used without leaving the console. It also has auto completion on the tab-key.

The second option, the graphical user interface, was introduced in version 3.1 and provides the known features of the metasploit framework console and many new features. To find and execute an exploit in this interface, just type the name or a part of the name in the search box and hit enter or the button labled 'find'. Now in the window below, a tree will show available exploits that fit your search request. They can now be executed or you may inspect their source code. If an exploit is executed, a wizard will guide the user through the entire process of how to set it up correctly. Afterwards the result is presented in the main window under the modules output tab.
(Sourche:self-made)

The third option is accessible by executing the 'msfweb' command to start up a server. The default interfaces for this server is the loopback (127.0.0.1) with the port 55555. After a log message inicated that the server is running, it is accessible by opening the following URL in any Web-Browser:
'htts://127.0.0.1:55555/'
On this server the metasploit framework works as it would in a command line interface, and can acces all ressources as you would there. One notable difference is that, if a session is running, it may be accessed via the session link.

### Architecture
Metasploit is written in Ruby and has been developed for many years. As one would imagine, over the years there have been many exploits added to its library so at first glance the size and complexity of the programm may seem overwhelming. But to work with it a high level overview of the programm is usually sufficient.

[Source](https://www.offensive-security.com/metasploit-unleashed/metasploit-architecture/)

Either by working with it or by inspecting it beforehand one will have to delve into the filesystem of metasploit which is organized rather intuitive.

Quelle: Selbst gemachter Screenshot

Some of the more important directories are briefly touched on below:
#### Data
This directory contains files which are used to story binaries which are required by certain exploits, wordlists, images etc.
Generally speaking there are 2 differnty data stores. The one in the depiction above, the so called 'global data store' which can be accessed by using the 'setg' or 'unsetg' commands. And the second one are the data stores that each seperate modules have.
#### Documentation
This directory contains, as the name suggests, the documentation of the metasploit-framework. For beginners most noteably the "developers_guide.pdf.gz" which is a quite extensive 78 page document about the framework which also clears up questions like "Why Ruby?"

#### Lib
This directory contains the code that makes the framework what it is. The 'rex' folder deserves a special mention. The shorcut stands for 'Ruby Extension Library' and it is a collection of classes and modules which are usefull to more than one project. The more usfull ones provided by 'rex' are listed below. For more details check out the documentation.
* Assembly
* Encoding
* Exploitation
* Jobs
* Logging
* Opcode Database
* Post-exploitation
* Protocols
* Services
* Sockets
* Synchronization
* UI

#### Modules
This directory is where not only modules for exploits but also auxiliary and post modules, payloads, encoders as well as nop generators can be found.
* Auxiliary: includes, port scanners, fuzzers, sniffers and the like
* Encoders: are used to ensre that the payload is not detected by any prevention software
* Evasion
* Exploits
* Nops: keep the payload size consistent and are used for stack overflows
* Payloads: are the pices of code used in different exploits. For example to elevate privelege level. They are compiled at runtime and fuse together stagers with their stages.
* Post

#### Plugins

#### Scripts
This directory is of special interest for this paper sinc the object of our interest, meterpreter can be found here among other scripts.

#### Tools
This directory contains useful command-line utilities.

### Functionality
If used in the command line interface, the first step of actually using the Metasploit framework is to check which modules are currently available with the 'show all' command. If required it is alos possible to look for a certain type of exploit by using the command 'show moduletype'. After an exploit is chosen, it may be executed via the 'use' command.
The next step in executing the exploit is to determine available options. Some are required for the exploit to work like 'RHOST' and 'RPORT' to select the target machine where the exploit is supposed to be run. To find out about available options use the 'options'command beforehand. Some, more complex exploits have a plethora of additional options which can be viewed with the 'show adcanved' command.
Some exploits have the additional handy command 'check'. The purpouse of it is to test if the target machine is vulnerable to the exploit without actually exploiting it. This is a handy tool for etchical hackers.
After such an vulnerability is found a payload can be sent over which is actual code that runs on the target system. Which payloads are available depends on the exploit that is beeing used. The command 'show payloads' gives an overview of the ones that are compatible with the currently used exploit. Afer the choice is made, use the 'set' command to specify it. Now the command 'show options' display the available options. Most of the time one of the options is mandatory to choose and specify. Some payloads also have advanced options like the exploits before.
#### Payloads
In the metasploit framework payloads refer to modules which are used for different exploits. Those modules or payloads can be differentiated as follows:
* Singles: As the name suggests are self contained payloads that just do one thing on the target machine, such as adding a user.
* Stagers: are supposed to set up a connection to the target machine. Metasploit will use the best possible stager and if that one doesnt work, will use others.
* Stages: Need stagers to work. They are transmitted via the established connection of the stager to the target machine and are then used to further explit it. Examples for stages are:
* VNC Injector
* iPwn Shell for iPhone
* Meterpreter

## Meterpreter
Meterpreter is an abreviation for Meta-Interpreter. It is an payload which is included in the Metasploit Framework. Originally it was developed for Metasploit 2.x by Matt Miller under the hacker moniker of Skape. It is used after an exploit was used to gain access to a system to further interact with it by providing an interactive shell. The way this payload operates makes it very hard to detect since it is no process itself but injected into processes which are already running on the target system. This also means that it is executed from memory only making it even harder to detect for Anti-Virus software. The payload itself is very flexible allowing for great customization for developers. Each may write their own extension in form of a shared object file (DLL-dynamic link library) which are then injected into memory.

### Goals
The short version is that Meterpreter is supposed to give the attacker access to a command interpreter on the target machine which is very hard or idealy impossible to detect with forensic tools. To achieve this goal while designing meterpreter, Miller had the following 3 requirements:
#### Stealthy
The payload has to be stealthy, or how he put it in the documentation:
> Must not create a new process (source:1)

It should be very hard to detect with forensic tool after meterpreter was used on the target system. To reach this goal, 3 sub-criteria had to be met:
* It was designed to just reside in memory and never write on the disk.
* It resides inside other, already existing processes. Should the process in which it currently recides finish, meterpreter 'hijacks' another one that is currently running.
* It uses encrypted communication.

#### Powerful
Having access to a command line interface on the target device is useless if the priveleges are not sufficiently elevated.
> Must work in chroot’d environments (source:1)

* Meterpreter utilizes a channelized communication system.
* The TLV protocol has few limitations.

#### Extensible
A usefull tool does one thing and one thing well as we know. But a adaptable tool that can change, according to who uses it, what it is used for, and in what environment it is used, is arguably an excellent tool.
> Must allow for robust extensibility (source:1)
This goal lead to the following functions:
* Meterpreter can be augmented at runtime. This means for exmaple that a library or extension can be loaded up to the server to gain more options.
* augmentation at runtime means that Meterpreter does not have to be rebuilt
This whole process takes a few seconds to complete.

### Usage
Meterpreter itself was developed for Metasploit. Unsurprisingly the easiest way to use it is via this framework. It was implemented on windows but since its design makes it fully portable it may be applied to a variety of other operating systems like Linux, or Android. When used via the metasploit framework to use an exploit on a windows target machine, one of 3 payloads can be chosen. Each of which differ in the way they establish a connection between the client, on the machine of the attacker and the server, on the machine of the target.
* win32_bind_meterpreter
This payload establishes a connection from the attacking machne to the target machine. After this is done the server gets uploaded and the connection is further used.
* win32_reverse_meterperter
This payload estblishes a connection from the target machine to the attacker. After this is done the server gets downloaded from the attacker machine and the connection is again used further.
* win32_findrecv_ord_meterpreter
This last payload is the most stealty since it does not establish new connections and can bypass firewalls that way. It looks for the file descriptor that the exploit was triggered from and uses it to upload the meterpreter server. Afterwards the same connection is used as a means of communication.

Which payload is used depends on the exploit and conditions of the envicronment in which it is deployed like the
configuration of the firewall of the target machine.
After starting up the metasploit framework and seeing the 'welcome screen', pick an exploit that uses meterpreter as a post exploitation tool. For demonstration purpouses one may use 'Tester'. After that, secelct the desired payload, in case of 'Tester' it doesn't matter which one of the three. In the demonstration below I used **win32_reverse_meterperter**
(Screenshot of payload deployment)
As seen in depiction X it is then required to define:
* RHOST: which represents the IP of the host or client machine
* RPORT: which represents the outgoing port of the host or client machine
* LHOST: which represents the IP of the target or server machine
* LPORT: which represent the incomming port of the target or server machine
In the case of this test, the IPs are loopback.
(screenshot of the fireup of meterpreter and the help commands result)
Depiction XY shows the currently available commands on the base version of meterpreter. Depending on what the attacker wants to achieve, additional libraries may be uploaded during deployment. After doing that, the help command lists the newly available commands as well.
(screenshot of uploading lib and help)

### Functionality
#### TLV - Type-Length-Value
For meterpreter to be as expandable as it is, the underlying packet structure (parsing and transmission) had to be well defined. This lead to the choice of a Type-Length-Value structure, or TLV for short. This packet structure allows for packets to have arbitrary lengths, and does not require for the parsing code to understand the format of the data that is received which in turn allows for all sorts of data to be sent from the server to the client.
The structure of the actual package is a little bit different than the name would suggest. The correct order would be Length-Type-Value:
* **Length**: (32 bits, network byte order): The length field contains the length of the TLV including the Length, Type and Value fields
* **Type**: (32 bits, network byte order): The type field holds the arbitrary data type which is used to inidcate the format of the value.
* **Value**: (0..n bist): The value field holds arbitrary data that is of the format specified in the Type field.

This structuring makes it possible to nest TLVs into one another to convey data that usually would be transmitted in some sort of header.

#### Structure
One TLV may contain zero of more TLVs in its Value field, and there are four types of packets, which indicate what type of packet is currently being transmitted or received.

| Name | Type |
| -------- | -------- |
| PACKET_TLV_TYPE_REQUEST | 0x00000000 |
| PACKET_TLV_TYPE_RESPONSE | 0x00000001 |
| PACKET_TLV_TYPE_PLAIN_REQUEST | 0x0000000a |
| PACKET_TLV_TYPE_PLAIN_RESPONSE | 0x0000000b |

The only difference between the 2 packet types with 'PLAIN' in their name ist, that even if encryption is enabled, which is optional for the other two packet types, thoes packets will be transmitted in plain text.

#### Definec TLVs
The technique of nesting TLVs in one another is also used to replace the header field of a standard IP packet. The information which is usually conveyed in such a field is still required for communication. So it is simplay put into a TLV packet which is in turn nested into another TLV's 'Value' Field. This leads to a number of predefined TLVs which are used by meterpreter. This feature may also be used for building extensions for meterpreter. These predefined TLV's can be uniquely identified by their least, and most significant bytes. The most significant hold the meta-type information, and the least significant the unique identifier.
The meta-type information is used to validate an argument, like verifying that an argument supplied as a string is null-terminated. It is also used for parameter decoding. All meta-types are listed below:

| Name | Value |
| -------- | -------- |
| TLV_META_TYPE_NONE | 0 << 0 |
| TLV_META_TYPE_STRING | 1 << 16 |
| TLV_META_TYPE_UINT | 1 << 17 |
| TLV_META_TYPE_RAW | 1 << 18 |
| TLV_META_TYPE_BOOL | 1 << 19 |
| TLV_META_TYPE_GROUP | 1 << 20 |
| TLV_META_TYPE_COMPLEX | 1 << 21 |

Off of those 7 meta-types, a list of predefined TVLs have been developed which provide core functionality to meterpreter.
| Name | Value |
| -------- | -------- |
| TLV_META_TYPE_NONE | 0 |
also called TLV_TYPE_ANY, unused Datatype.

| Name | Value |
| -------- | -------- |
| TLV_META_TYPE_STRING | 1 |
also called TLV_TYPE_METHOD, holds a method or command which is to be executed by server or client.

| Name | Value |
| -------- | -------- |
| TLV_META_TYPE_STRING | 2 |
also called TLV_TYPE_REQUEST_ID, holds a unique request ID to associate requests and responses.

| Name | Value |
| -------- | -------- |
| TLV_META_TYPE_GROUP | 3 |
also called TLV_TYPE_EXCEPTION, which in turn holds the TLV_META_TYPE_EXCEPTION_CODE and TLV_META_TYPE_EXCEPTION_STRING.

| Name | Value |
| -------- | -------- |
| TLV_META_TYPE_UINT | 4 |
also called TLV_TYPE_RESULT, as the name suggests it holds the result of a given operation.

| Name | Value |
| -------- | -------- |
| TLV_META_TYPE_STRING | 10 |
also called TLV_TYPE_STRING, holds generic strings.

| Name | Value |
| -------- | -------- |
| TLV_META_TYPE_UINT | 11 |
also called TLV_TYPE_UINT, holds generic integer values.

| Name | Value |
| -------- | -------- |
| TLV_META_TYPE_BOOL | 12 |
also called TLV_TYPE_BOOL, holds a generic boolean.

| Name | Value |
| -------- | -------- |
| TLV_META_TYPE_UINT | 25 |
also called TLV_TYPE_LENGTH, holds an arbitrary length.

| Name | Value |
| -------- | -------- |
| TLV_META_TYPE_RAW | 26 |
also Tcalled LV_TYPE_DATA,

| Name | Value |
| -------- | -------- |
| TLV_META_TYPE_UINT | 27 |
also called TLV_TYPE_FLAGS, holds arbitrary flags.

| Name | Value |
| -------- | -------- |
| TLV_META_TYPE_UINT | 50 |
also called TLV_TYPE_CHANNEL_ID, holds a uniquie channel identifier for a given channel.

| Name | Value |
| -------- | -------- |
| TLV_META_TYPE_STRING | 51 |
also called TLV_TYPE_CHENNAL_TYPE, holds the type of channel which was previously allocated using the TLV_TYPE_CHANNEL_ID. Is also used to keep track of where ressources originate.

| Name | Value |
| -------- | -------- |
| TLV_META_TYPE_RAW | 52 |
also called TLV_TYPE_CHANNEL_DATA, containing arbitrary data.

| Name | Value |
| -------- | -------- |
| TLV_META_TYPE_GROUP | 53 |
also called TLV_TYPE_CHANNEL_DATA_GROUP, and allows for containing multiple TLV_TYPE_CHANNEL_DATA TLVs within one TLV.

| Name | Value |
| -------- | -------- |
| TLV_META_TYPE_UINT | 300 |
also called TLV_TYPE_EXCEPTION_CODE, holds an integer which identifies an exception.

| Name | Value |
| -------- | -------- |
| TLV_META_TYPE_STRING | 301 |
also called TLV_TYPE_EXCEPTION_STRING, holds the explanation of the previously occured error in string form.

| Name | Value |
| -------- | -------- |
| TLV_META_TYPE_STRING | 400 |
also called TLV_TYPE_LIBRARY_PATH, holds the path to a library which is about to be loaded.

| Name | Value |
| -------- | -------- |
| TLV_META_TYPE_STRING | 401 |
also called TLV_TYPE_TARGET_PATH, holds the target path to upload a library, when its being saved to the disk on the remote client.

| Name | Value |
| -------- | -------- |
| TLV_META_TYPE_STRING | 500 |
also called TLV_TYPE_CIPHER_NAME, holds the name of the cypher which is used in the encryption of the datastream between client and server.

| Name | Value |
| -------- | -------- |
| TLV_META_TYPE_GROUP | 501 |
also called TLV_TYPE_CYPHER_PARAMETERS, used to negotiate an encrypted channel between client and server.

#### Connectivity
The connection between server and client is initiated by the server (i.e. the target machine), after the metasploit framework used an exploit to gain access to the system, which then sends a banner message to the client to signal the established connection.

[Source](https://www.javatpoint.com/meterpreter-in-ethical-hacking)

#### Encryption
At this point it is possible to enable enryption of the communication by issung the command 'initcrypt' on the client machine. This command needs to be supplied with a cypher which the client then sends as a plaintext packet to the server via the method 'core_crypto_negotiate'. This includes a unique request identifier since a response is expected. This packet also needs to contain the TLV_TYPE_CYPHER_NAME and optionally the TLV_TYPE_CYPHER_PARAMETERS.
If everything works as expected the server responds with the 'core_crypto_negotiate' method back including the optional parameters if provided.

#### Libraries
Loading a new library very similar in complexity and method to enabling encryption. Depending on the parameters of the 'loadbib' command, the employed mechanism varies. In a situation where the library is loaded from a path on the remote machine, and no uploading is taking place, the packet flow looks like this:
1. The Client transmits the request with the method 'core_loadbib' which includes a TLV_TYPE_LIBRARY_PATH TLV with the location of the remote server where the library is located.
2. The Server transmits the response 'core_loadbib' back to the client. If the library was loaded successfully, the TLV_TYPE_RESULT parameter will be set to zero. In the other case, the response contains the exception and its data.

## Practical Demonstration
### Phone-Hack

## Präsentation
https://prezi.com

## Sources
@technical{meterpreter_documentation,
title={Metasploit's Meterpreter},
author={skape, [e-mail]},
url={http://hick.org/code/skape/papers/meterpreter.pdf},
year={2004},
month={Dec},
day={26}
}

@technical{metasploit_framework_user_guide,
title={Metasploit Framework User Guide},
url={http://cs.uccs.edu/~cs591/metasploit/users_guide3_1.pdf},
}

https://www.hackingarticles.in/hack-call-logs-sms-camera-remote-android-phone-using-metasploit/