Metasploit 6 Now Under Active Development

Today the Metasploit team is pleased to announce active development of Metasploit Framework 6.0, available now for testing and community feedback. Initial Metasploit 6 features include end-to-end encryption of Meterpreter communications across all five implementations (Windows, Python, Java, Mettle, and PHP), SMBv3 client support to further enable modern exploitation workflows, and a new polymorphic payload generation routine for Windows shellcode that improves evasive capabilities against common antivirus and intrusion detection system (IDS) products.

This initial feature set marks a transition toward secure communications and encryption by default across key components of Metasploit Framework. Initial Metasploit 6 features also increase complexity for creation of signature-based detections for certain network operations and Metasploit’s main payload binaries. Metasploit users and developers can expect further additions to and refinement of version 6 features over the coming months.

Important note: Metasploit 6 incorporates backwards-incompatible changes for payload communication, meaning payloads generated with previous Metasploit versions will be unable to connect to Metasploit 6 and vice versa. Because of this incompatibility, users should not update to Metasploit 6 during active operations unless they are prepared to lose their sessions.

Rapid7 and the Metasploit team would like to extend our deepest thanks to longtime contributor OJ Reeves for his tireless efforts implementing and refining many of the improvements in the latest version of Metasploit.

Expanded Encryption

Starting in Metasploit 6, all Meterpreters will use AES to encrypt their communications with the Framework. End-to-end encryption offers operators two noteworthy advantages: First, the encryption obfuscates the traffic, making signature-based detections of established communication channels much more difficult. Secondly, sensitive information (such as passwords) transferred from the compromised host to the Framework is now protected in transit.

Metasploit 6 also improves the Framework’s SMB client to support SMB version 3. SMBv3 added support for encryption, which Metasploit will now use by default when available—and which, as with Meterpreter encryption, will increase complexity for signature-based detections used to identify key operations performed over SMB. We’ve updated a number of popular Metasploit modules to use the new SMB client so they can be used in environments where SMBv3 is the only version available; some older modules may be updated at a later time (or not at all). Some noteworthy modules that now support SMB versions 1, 2, and 3 include:

• exploit/windows/smb/psexec
• exploit/windows/smb/webexec
• auxiliary/admin/smb/psexec_ntdsgrab
• auxiliary/scanner/smb/smb_version
• auxiliary/scanner/smb/smb_login

Cleaner Payload Artifacts

Meterpreter, Metasploit’s primary payload, includes a few additional improvements on top of the encrypted communications channels. DLLs used by the Windows Meterpreter now resolve necessary functions by ordinal instead of name. This means the standard export ReflectiveLoader used by reflectively loadable DLLs is no longer present in the payload binaries as text data. Additionally, the commands that Meterpreter exposes to the Framework are now encoded as integers instead of strings. This particularly benefits stageless Meterpreters on native architectures (such as Windows and Linux) since these strings are no longer in the binaries.

The old Mimikatz Meterpreter extension has been removed in favor of its successor, Kiwi. Attempts to load mimikatz will load Kiwi for the foreseeable future.

Finally, the vast majority of Windows shellcode payloads (like windows/meterpreter/reverse_tcp) use a common stub for invoking Windows API methods. This stub is known as the block API and accounts for almost half the size (130 bytes for x86 and 200 bytes for x64) of some of the smaller payloads. This (previously) static stub was low-hanging fruit for signature-based shellcode detection: Two signatures—one each for x86 and AMD64—could match almost all of Metasploit’s unencoded Windows payloads. To address this, Metasploit has replaced the static generation routine with a randomization routine that adds polymorphic properties to this critical stub by shuffling instructions around each time. This provides the anti-signature benefits historically bestowed by encoding without requiring the payload to be self-modifying (and thus to exist within an RWX segment that is often identified as malicious behavior in and of itself).

Updating to Metasploit 6

The 6.x development branch of Framework is available on GitHub, with the usual disclaimer that future development will include breaking changes and experimental features. Existing users can upgrade to version 6 using the msfupdate utility. Alternatively, git users can clone the Metasploit Framework repository (master branch). New users can obtain a fresh install without git using the open-source-only nightly installers or the binary installers (which also include the commercial edition).

We’ve reached out to the maintainers of popular security distributions—including Kali Linux, BlackArch Linux, and Parrot OS—to request that they continue packaging the stable 5.x branch of Metasploit Framework until version 6 is eventually ready to package as a stable major version release in distros with broad adoption. For documentation on these and future Metasploit 6 features, keep an eye on the Metasploit wiki.

Initial features included in Metasploit Framework 6.0 will also be incorporated into the upcoming Metasploit Pro 4.18 release, due in late August.