Blog  |  Walkthroughs  |  Talks  |  About   

Why Your Payloads Aren't Working

Created: September 08, 2019 | Updated: January 23, 2020
This blog is intended to be an introduction to payload generation and environmental factors to consider when crafting payloads during a penetration test, or red team engagement. Although seemingly elementary, these concepts carry over into multiple tools commonly used and stress the importance of situational awareness.

To begin, let's first dive into two types of payloads for gaining a remote shell on a target system:

Network Positioning

Now that we have our payloads straightened out, the first factor to consider before crafting a payload is your position on the network. Often times this will be predefined, and discussed with the client prior to the engagement. For example, you may perform an assumed breach scenario where you are on site, plugged into their local network. In this situation, you are likely on the same subnet, or within reach, of the systems you are trying to exploit. This would allow for either a reverse or bind payload to be effective, as there are no technical controls blocking your path. However, it is not always that easy...

Assume you forgo the onsite visit and perform the assessment remotely, or gain access to the client's VPN during the external portion of the test. Once on the VPN subnet, you have no problem reaching domain resources, but find that clients are unable to connect back to your system due to network restrictions. This situation is a prime candidate for a bind payload, since we only have a one way connection and are dealing with internal systems.

Side-Note: Use extreme caution before executing a bind payload against a public facing system and avoid at all cost! If its your only option, consider getting the client involved before executing.

Host Configuration

So you are on the internal network and have full connection to the target system but your reverse shell payloads still aren't working, whats wrong? Another area to consider in payload creation is your systems configuration, and positioning within itself. Many testers utilize the Kali Linux distribution within a virtual machine (VM) for penetration testing. This makes it easy to take a clean snapshot prior to the assessment, perform your testing, and revert back to ensure no client data is unintentionally stored. However, depending on the configuration, the network adapter settings can also restrict connections and should be accounted for.

The screenshot above demonstrates the virtual network adapter configurations in VirtualBox, the most common being "NAT" and "Bridged Adapter". In a nat'ed configuration, information is run through the host system and only allows outbound connections from the VM. In which case, even if we have a bidirectional path to our target, only bind payloads will work effectively.

When using a bridged connection, the virtual machine acts independently from the host and even uses DHCP to request its own IP address on the network. Should you be on the local network using a bridged adapter, further investigation should be conducted and may indicate a lack of Network Access Controls (NAC) inplace. However, for our purposes, we can then perform reverse shell payloads given the client has a connect back to the VM's own DHCP address. Additionally, this is when tools like responder, and ntlmrelayx come into play, which require the ability to take over the VM's network interfaces and interact with traffic on the local network.