Meterpreter Survey 2015: You spoke, we listened, then wrote a bunch of code.

Last updated at Tue, 25 Apr 2023 22:47:00 GMT

The Survey

One month ago we asked the community for feedback about how they use Metasploit and what they want to see in the Meterpreter payload suite going forward. Over the course of a week we received over 400 responses and over 200 write-in suggestions for new features. We have spent the last month parsing through your responses, identifying dependencies, and actively delivering new features based on your requests. These requests covered 20 different categories:

We merged similar requests, removed duplicate items, and reworded many of the suggestions so far. For the issues specific to Meterpreter, you can now find them listed on the Meterpreter Wishlist. If you don't see your feedback listed, it was either merged into another item, or wasn't Meterpreter specific (Metasploit features, AV feedback, RPC API feedback, etc).

After parsing through these, we grouped up similar items, figured out the missing dependencies, started building out a rough plan for 2015, and got down to business. Over the last two weeks we have made some serious progress, mostly focused on the work that has to be done before we can tackle the bigger features on this list. The wishlist items marked [DONE] were the result of this first sprint while the rest of the items listed as [IN PROGRESS] are being actively worked on by either myself, OJ Reeves, or Brent Cook. While there is no realistic chance that we can get to every feature that was submitted, we are going to try to build out enough supporting functionality that the community can tackle the wider group of features with minimum pain. If something jumps out that you want to work on, please join the IRC channel and see if there are any blocking issues before diving in. Once you have a green light, send us a pull request once you are ready for feedback. If you can't contribute, no worries, keep reading for what is done so far, and where we are headed.

Attacks Have Changed

The Metasploit Project started in 2003 with a broad goal of sharing information about exploit techniques and making the development of new security tools much easier. This was a time when shellcode golf was the name of the game, SEH overwrites had hackers yelling "POP, POP, RET!", and databases of opcodes at static addresses made exploit development possible for systems you didn't even have. Fast-forward a decade and exploit mitigations at the OS level have made traditional exploit methods obsolete and complicated reliable remote exploitation; at least for memory corruption vulnerabilities. At the same time, anti-virus tools, anti-malware network gateways, and SSL-inspecting web proxies have become a thorn in the side of many professional penetration testers.

This shift away from memory corruption vulnerabilities hasn't decreased the number of compromises, nor has the availability of new security technologies, but the way networks get compromised has changed. As operating system and compiler vendors made memory corruption vulnerabilities more complicated on end-user and server platforms, attackers have shifted to the weakest links, which are typically the actual employees, their devices, and their passwords. Metasploit has continued to evolve to support these use cases, with a focus on client-side applications, web applications, embedded devices, and attacking the credentials themselves. The one area where Metasploit hasn't changed however, has been payloads.

For the better part of 12 years, Metasploit payloads and encoders have had one primarily goal: fit inside of the exploits. This works great when Metasploit users are getting shells through memory corruption flaws, but doesn't make a lot of sense when attacks can deliver a multi-megabyte executable or JAR file onto the target. As a result, Metasploit payloads have been artificially constrained in terms of functionality and error handling. That has now changed. Payloads and encoders can now opt-in to new features, better error handling, and network-level evasion when they have the room for it. This is now enabled by default when using msfvenom (specificy -s to tell the payload how much space it can use).

Separate, but related, was the slow startup time of the Metasploit Console (msfconsole). A few months ago, many users had to wait up to 30 seconds to use msfconsole on a modern system. After the switch to Ruby 2.1.5, this dropped to under 10 seconds for most users. Most recently, payloads now cache their static size, allowing us to use Metasm to generate and compile assembly on the fly, and knocking quite a bit of processing out of the startup time. Running the latest version of msfconsole on a SSD-enabled system with Ruby 2.1.5 can result in startup times between 1 and 5 seconds.

These two changes pave the way to solving the number one piece of feedback: Payload size doesn't matter that much anymore. Many people use Metaslpoit payloads without exploits, either by delivering the payloads manually, or combining them with third-party tools like SET, and these payloads should support advanced options and handle network errors gracefully. Metasploit payloads now selectively enable functionality based on your use case and the available space.

Sprint 1 Features

The features below were some of the first dependencies needed to really tackle the features requested in the survey. These are available in the Metasploit Framework master branch today and will be going out to Metasploit Pro, Metasploit Express, Metasploit Community, and Kali Linux users this week.

HTTP Stagers

The reverse_http and reverse_https in stagers have been around for a few years and they solve a number of problems related to session egress within corporate networks, but they were starting to get dusty. First of all, we continued to add new versions of these payloads to handle specific use cases, like proxies, proxy authentication, and hopping through intermediate web services. We are now actively working on a complete refactor that merges all of this functionality into a smaller set of smarter payloads. In addition to bug fixes, better error handling, and size-aware feature selection, these payloads have been expanded with some new functionality:

Long URIs: The reverse_http and reverse_https stagers now use much longer URIs by default. The old default was to use a 5-byte URI, but these were starting to get blocked by a number of web proxies. The new default is use a random URI between 30 and 255 bytes.

WinHTTP: Borja Merino submitted a really nice set of reverse_winhttp and reverse_winhttps stagers. These stagers switch to the WinHTTP API (from WinInet), which helps bypass certain anti-malware implementations, and builds the base for a number of new features. The development started off as Borja's PR and eventually got rolled into the new Metasm base payload.

SSL Validation: SSL certificate verification is now available in the reverse_winhttps stager. You can enable this by generating a payload with the HandlerSSLCert option set to the file name of a SSL certificate (PEM format) and setting the StagerVerifySSLCert option to true. The Metasploit exploit or exploit/multi/handler listener should set these options to the same value. Once these are set, the stager will verify that the SSL certificate presented by the Metasploit listener matches the SHA-1 hash of the HandlerSSLCert certificate and will exit if they don't match. This is a great way to make sure that a SSL-inspecting proxy isn't monkeying with your session and provides stager-level authentication that is resistant to man-in-the-middle attacks, even if the target system has a malicious CA root certificate installed. If you want to make this apply to all future uses of reverse_winhttp, use the setg command in msfconsole to configure HandlerSSLCert and StagerVerifySSLCert, then save to make these the default.

We still have a lot more work to do on HTTP stagers, so keep an eye on ticket #4895 if you want to keep up on the latest changes.

Meterpreter SSL Verification

Updating the WinHTTP stagers to support SSL Verification is only part of the puzzle. OJ Reeves also delivered SSL certification validation in the Windows Meterpreter payloads. These can be enabled using the same HandlerSSLCert and StagerVerifySSLCert options as the stagers. If you set these within an exploit, the entire process is automatic, but if you are using exploit/multi/handler, be sure to set them both in the msfvenom generation (stageless or otherwise) as well as the listener. Note that verification occurs after the HTTP request has been sent. As a result you will get a "dead" session when the Meterpreter is enforcing this setting and doesn't see the right SSL certificate. We are looking into better solutions for this going forward.

Meterpreter "Stageless" Payloads

One often-requested feature was the ability to run Meterpreter without the shellcode stager. A project called Inmet (ultmet.exe) is best known for providing a stageless metsrv in the past, but this implementation wasn't as smooth as it should have been due to incompatibilities in the framework. Over the last two weeks, OJ Reeves has delivered an impressive approach to stageless Meterpreters and I strongly recommend that you check out his post on the topic. This is the first step to implement many of the advanced features requested in the survey.

Meterpreter Unicode (최고)

Nearly all Meterpreter payloads will support Unicode file and directory names, converting between UTF-8 and native string implementations as needed. If you used Metasploit outside of the US in the past, you may be familiar with the EnableUnicodeEncoding option in Meterpreter. Previously, this was set to true by default, and would translate garbled Unicode names into identifiers that looked like $U$-0xsomething. This made it possible to work with non-native encodings, but it wasn't much fun. Fortunately, so long as your Linux terminal supports UTF-8, this is no longer necessary. Windows users still need the EnableUnicodeEncoding crutch since Console2 doesn't implicitly support Unicode, but everyone else should be good to go for full Unicode support going forward.

Unicode is still  a work in process, but it is nearly complete across all Meterpreter payloads:

• The Python and Windows Meterpreters have full Unicode support for file system operations.
• The PHP Meterpreter has support only on non-Windows platforms due to API limitations.
• The Java & Android Meterpreter have a pending pull request adding support for Windows and non-Windows.

Note that Unicode is not automatically translated for shell sessions (or shell channels in Meterpreter). This is a bit more complicated, but is on our radar for long-term support.

Meterpreter MS-DOS "short" Names

Meterpreter now displays MS-DOS 8.3 "short" names when you use the ls command with the -x parameter on Windows. This makes it easy to copy, rename, and generally manipulate a file or directory with an unwieldy name. A quick and easy win and really useful in a pinch.

Next Steps: April 2015

Our plans for the next month are centered around improving the Meterpreter code organization and build process, supporting unique embedded payload IDs (a precursor for universal listeners), improving the reliability and resilience of all Meterpreter transports, adding support for live transport switching to Meterpreter, and improving the usability of all of these features as we go. There is a ton of work to do, but these efforts will lay the groundwork for approaching the rest of the wishlist going forward. One of our goals is to maintain complete backwards compatibility with both old Metasploit installations and their associated payloads. More often than not this means taking two steps forward and one back as we make small incremental changes in quick succession. In addition to the fun part (the code), we will be updating the test suites and documentation as we go as well.

May 2015 and Beyond

We are looking at May as the time when we can start seriously considering BIG features. These may include remote scripting engines, enhanced pivoting, pluggable transports, and a deep dive into mobile device support. Figuring out what is going to fit and how to prioritize it is going to be driven by engineering challenges as much as community feedback and contributions. As attacks change, so will Metasploit, and the time has come for payloads to take the next big step.

Onward, through the pull requests!

-HD