Why Your Payloads Aren't WorkingCreated: 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:
- The first type, Reverse payloads, are just as they sound. Once executed on the target, the host will make a connection back to the attacker's system, on a predefined port, to initialize a shell. The attacker must configure a "listener" in order to receive the connection. This type of payload can be used when a firewall restricts incoming connections, or you do not want to expose an open port; e.g. internet facing systems. NetCat can be used to demonstrate this type of payload below:
- Bind payloads on the other-hand, do not require the target to have a direct connection back to the attacker. Once the payload is executed, the target system opens the designated port and allows the attacker to connect. This approach is especially helpful when the attacker has a clear connection to the host, but the host cannot connect back to the attacker; often the result of network restrictions and segmentation. Again, NetCat is used below to demonstrate a bind shell payload:
Network PositioningNow 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 ConfigurationSo 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.