RFC: Enhanced Payload Chaining

[smcintyre-r7]

Problem

Metasploit provides payloads that are delivered with exploits to be executed by the target system. These payloads are however relatively opaque, the user has the option to select a stager and a stage with little ability to customize anything else. This limits how a Metasploit user can leverage a particular exploit module to scenarios that the module author had anticipated. Currently, many of these scenarios are handled through the "Targets" field of a module, where the user can select the type of payload they would like to use and the module author provides a sort of shim to make it work.

Take for example the common scenario of an exploit that targets Windows and is capable of executing an operating system command. It's possible to leverage it to execute binary payloads on disk via command stagers, in memory via powershell, powershell native stagers, and of course raw OS commands. In this scenario, for the module author to provide each these to the user, they would need to explicitly support them through modification libraries provided by Metasploit such as the Powershell and CMDStager libraries. This puts the additional effort on the module developer and provides an inconsistent experience for the user.

Module authors should be able to define a set of constraints for their payload such as that it must be ARCH_CMD, can only be x characters in length, may not contain y characters and can be executed multiple times. From there the Metasploit framework could provide reusable logic to allow converting payloads as necessary through provided modifiers to meet the defined constraints.

Additionally, some users may want to utilize modifiers in the payload chain that perform no conversion but rather alter the behavior. An example of this may be a modifier that unhooks known AV/EDR hooks in memory before executing it's stage. Another example could be a modifier that executes the stage by injecting it into a process that the user has specified. Currently, Metasploit includes some functionality for payloads that would be well suited as modifiers, such as some of the Linux payloads options PrependFork, PrependSetuid, and the Windows option PrependMigrate.

Solution

Metasploit should allow "payload modifiers / adapters" that accept a payload and output a payload changing it based on the defined bahvior.

• Metasploit would be updated to allow an arbitrary number and order of adapters (but limited by module constraints) in a similar way to how payload stages and stagers are combined
  • Encoders may need to be able to be applied both on the final result and intermediary layers. If for example, an adapter has bad characters of its own, an encoder may be necessary to address the limitation in a reusable manner. Otherwise it'll have to be implemented in one-off encoding like it's done now, usually through base64 encoding.
• Adapters could be implemented to perform basic architecture conversion
  • ARCH_CMD -> ARCH_PYTHON, ARCH_RUBY (through invoking the correct interpreter)
  • ARCH_PYTHON -> ARCH_X86 / ARCH_X64 (through the C-ffi provided by ctypes)
• Adapters could define injection techniques
  • Windows ARCH_X* -> Early Bird, Process Hollowing
  • EDR, AV unhooking

The chaining to the end user for an exploit that expects an OS command on windows might look like:
set PAYLOAD cmd/psh/x64/unhook/meterpreter/reverse_tcp Where they are specifying they want an OS command that will execute powershell, perform unhooking before executing an x64 stub to remove memory hooks in the process and execute a reverse_tcp Meterpreter.

Further Considerations

The majority of exploit modules that are being added into the framework in recent years are not typical memory corruption exploits. In order to allow the user to select multiple payload options and thus provide them with valuable flexibility, module authors must explicitly define multiple targets, which was never the intention of the targets metadata within module.

[adfoster-r7]

I like the idea; Here’s some initial thoughts I had:

• Has there been any thoughts on how the user might configure each of the stages/adapters?
• The performance of payload generation is already quite slow in terms of bootup costs, to implement this successfully - I imagine we’d need to implement changes to how payloads are generated currently, but with performance improvements in mind. That might add to the cost of delivering this feature successfully.

[smcintyre-r7]

I'd imagine they'd use it in layers like:

set PAYLOAD cmd/psh/x64/unhook/meterpreter/reverse_tcp

Where in this scenario, we'd be saying (as read RTL):

• We want an AMD64 Meterpreter using the Reverse TCP stager and all of those options should be accessible through the datastore
• Then that should be wrapped within an AMD64 stub that performs "unhooking" or whatever. This is something that provides functionality and not a translation, both the input and output is AMD64 shellcode.
• Then we want to use a Powershell wrapper to load the AMD64 stuff, thus converting the raw shellcode into Powershell code.
• Finally we want that Powershell code to be executable as an OS command, so wrap all that again

As another example, if we wanted to go in the opposite direction and deliver a command payload over an exploit that expects native shellcode we could do set PAYLOAD x64/exec/adduser to run AMD64 shellcode that would invoke the OS command to add a new user.

I'm not 100% sure where the platform would go in the string, but the idea is they'd be loaded in the layers based on compatibility that we'd specify.

[schierlm]

If I could, I would upvote this 💯 times...

It's a pity that most exploits targeting a server/service implemented in Java need to implement ARCH_JAVA, ARCH_CMD and ARCH_WINDOWS and ARCH_LINUX so that everybody can use their favorite payloads and/or evasion techniques. And some exploits don't.

[smcintyre-r7]

This work has begun in #16186 which adds a new "adapter" payload type. The adapter is responsible for converting a payload from one arch / platform combo into another. It includes an initial example that adapts all Python payloads into to be ARCH_CMD / Unix compatible.

The current implementation is limited to a single-step conversion, meaning payloads can't be chained infinitely from ARCH_CMD to say ARCH_PYTHON and then back to ARCH_CMD by executing something akin to python -c "os.system(payload)". Each adapter can perform whatever actions it needs to adapt from one to another, but the framework itself won't recursively allow combining each.

Once that PR is landed, high on my list of next adapters to add would be for ARCH_X86 / ARCH_X64 on Windows to Powershell one-lines using our existing libraries.

[smcintyre-r7]

Once that PR is landed, high on my list of next adapters to add would be for ARCH_X86 / ARCH_X64 on Windows to Powershell one-lines using our existing libraries.

Submitted in #16548

[wvu]

Fantastic to see (and use) progress on this!