While the common targets of code execution exploits have shifted from servers to client desktops and laptops, most available exploit payloads in commercial and open-source penetration testing tools assume the target remains at a fixed network location. This may not be the case in many modern penetration tests. For example, the easiest way into a network may be through compromising a mobile laptop when it is associated to a ``hot spot'' wireless network. Existing penetration testing frameworks require that the target be continually reachable by the penetration tester in order to maintain command and control. An exploit payload that supports disconnected operation would allow the penetration tester to take advantage of the target's mobility in order to gain access to each network that the client connects to.
Several of the existing exploit payload systems offer dynamic scripting support. All of this support, however, is for attacker-side script execution. The execution of these scripts require a constant network connection to the penetration tester's machine. This may be infeasible when targeting mobile clients such as wireless laptops. In addition, attacker-side logic may require an infeasible amount of input/output to the target. For example, consider a payload with file searching logic. With attacker-side logic, this would require a large amount of uninteresting data to be downloaded to the attacker. Pushing the logic onto the target allows the searching to be performed where the files are local. While attacker-side scripts protect the payload logic, the cryptographic payload delivery system described above adequately protects transport of target-side payload logic to the target. The scripting engine could implement a similar cryptographic protocol or use an available SSL implementation to download scripts from the penetration tester.
The Lua programming language [17] was chosen as the target-side scripting language. Lua has many benefits for this type of application. Its interpreter is small (roughly 200k), very portable by virtue of a pure ANSI C implementation, and the Lua language is quite flexible and powerful. Lua has been historically popular as a scripting and extensibility language for games, however recently many open source security tools have begun to use it as well (Wireshark [18], NMAP [19], and Snort [20]).
The specific Lua interpreter chosen for the target-side scripting environment includes the C/Invoke [21] library, the LuaSocket [22] library, and the custom cryptographic routines used in the previously described secure payloads. This C/Invoke library allows purely scripted code to load and call into arbitrary dynamic library functions. C/Invoke supports marshaling basic types (machine types and strings), structures, and even supports callback functions written in Lua. For these reasons, it was chosen as an ideal dynamic interface to the system APIs. As an example, the Lua programmer would use the code in figure 3 to load the Win32 MessageBox() function and call it.
The LuaSocket library provides interfaces for TCP and UDP sockets as well as higher level protocols like HTTP, SMTP, and FTP. Combined with the included ElGamal key agreement and RC4 encryption routines, LuaSocket's network access can be used to establish secure connections back to the penetration tester for further instructions and to send back encrypted results. At present, the cryptographic support is limited to key agreement and symmetric encryption. This is enough, however, to protect the communication against eavesdropping.
The flexibility offered by the Lua scripting environment with full system library access allows the payload author to rapidly develop and deploy arbitrarily complex payloads. In addition, their implementation as purely textual scripting code allows them to be easily encrypted, signed, downloaded, and stored. Further work will build upon the customized Lua interpreter to build richer cryptographic capabilities.
In the section that follows, we describe several payloads that are difficult or impossible to implement with existing penetration testing tools but straightforward with a target-side scripting payload such as the one described. These payloads may also be implemented as free-standing executables, but there are several benefits to implementing them in a target-side payload scripting environment. As scripts, they are more transient than executables. For example, script code is easier to download and execute on-the-fly whereas an executable must be saved to disk first. This facilitates cleaning up target systems after the penetration testing engagement terminates. The target-side agent could even be configured to automatically remove itself and any downloaded scripts and data at a certain time coinciding with the end of the penetration test.
