Remove the encrypted shell payload and libs#21310
Merged
dledda-r7 merged 1 commit intorapid7:masterfrom Apr 16, 2026
Merged
Conversation
dledda-r7
approved these changes
Apr 16, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The encrypted_shell stage broke at some point when mingw changed from version 8 to version 10. You can confirm this by testing the c4e55f1 commit with the Ruby containers
ruby:3.1.5-bullseye(mingw 8) andruby:3.1.5(mingw 10). The unstaged payloadwindows/x64/encrypted_shell_reverse_tcpwill work with the older mingw but fail with the newer one. Kali is based on Debian, as is the Ruby container, meaning that this payload has been broken in Kali for about 2 and a half years without any reports. It's been broken in Fedora for longer. Since Metasploit v6, Meterpreter has offered built-in AES-encrypted sessions that do not require a database connection. Given that this has been broken for a long time with no reports, and that offering a more robust and intuitive solution for encrypted communications is the priority, it doesn't seem worthwhile to fix it. The reason I noticed this to begin with wasencrypted-shellcame up while reviewing the session types as part of #21191. I suspect that because the shell type is marked as encrypted-shell and not simply shell, the sessions aren't compatible with post modules that expect to run OS commands, which is why I went to test them in the first place.Closes #21071
Verification