We define our attacker to be a passive traffic eavesdropper or active traffic manipulator en route between the penetration tester's systems and the target client network, but not including an adversary on the client's network or a honeypot target. Our penetration test scenario is a client-side penetration test against a client's enterprise network. Client-side penetration tests using web and e-mail based attacks are becoming more common as Internet attackers have also been using these attacks more and more in recent years. In addition, while Internet perimeter security is a relatively mature and understood discipline, client security is still a difficult problem for most organizations.
An open problem with the existing exploit payload systems described above is cryptographically secure payload delivery and communication. Several of the systems described above transmit second-stage agent executables over their first stage payload's communication channels. While the second-stage agents employ strong cryptography to protect communications, they are sent in the clear over the unencrypted first stage payload communication channel. The executable agents are not polymorphic and may easily be fingerprinted and identified by a signature-based intrusion detection system as they are transferred to the target system. Because they are easily identified, an active attacker capable of performing a man-in-the-middle attack could also modify the executables in transit to the target system. The attacker could do this to gain access to the compromised hosts without prior knowledge of the vulnerabilities or exploits used by the penetration tester. Even if the agent executable themselves were made polymorphic, the custom protocols used to deliver them to the target system may still be identified and manipulated by an active attacker.
In a client-side penetration test, exploits are typically delivered as attachments to targeted e-mail messages or on web pages hosted on the penetration tester's web server. The attacks involve some amount of social engineering as the user must be convinced to open the e-mail message, attachment, or web page in order for the exploit to be attempted. Protecting the secrecy of these potentially proprietary exploits in use is a difficult problem that this work does not address. This work does, however, show how establishing a secure channel in the first stage payload protects all communications beyond the delivery of the exploit. This is sufficient to protect against a passive attacker. If the delivery of the exploit can be secured, for example, by sending exploit e-mails using Secure SMTP over TLS or hosting web-based exploits on a SSL web server with a certificate granted by a trusted root certification authority, then the communications between the penetration tester and target network can even be secured against an active attacker able to manipulate traffic. This design provides a secure mechanism for delivering the later-stage exploit payloads, as well as a secure transport for payload and remote agent command and control. This protects the penetration tester's tools, mission logic, and remote target communications from a passive adversary. The polymorphic encoding of the exploit and first-stage payload makes an active attack reasonably difficult, especially so if the exploit is delivered over SSL.