You have spent hours, perhaps days, probing a network's defenses, finding weaknesses and taking advantage of them to reveal more specific target hosts. After discovering a host that appears interesting enough to warrant further investigation, you focus and begin to dig even deeper. After some more time spent chipping away at the host, investigating each service, looking for public and private exploits, or maybe even buckling down and writing your own—a breakthrough:
C:\WINDOWS\system32>_
Great! Now what?
This is a question that regularly snakes its way into my head, but in this particular situation, there is already an answer. You have gained access to the host; now you need to make sure that you can continue to do so. Since it is unlikely that the administrator of this machine intended for you to gain entry like this (or for that matter, even at all), you will need some sort of backdoor into the system. Depending on the circumstances, this might be something as simple as adding an additional account to the system, or as comprehensive as a fully featured suite of tools that hides itself in memory, offering stealthy remote access and many other things. I will do my best to offer an example of each as well as a few more that fall somewhere in between.
With backdoors, emphasis is often placed on uses and functionality for the attacker or penetration tester, but often there are legitimate uses for administrators as well. It may be something as simple as having an easy way to administer the machine remotely. Perhaps the tables were turned, and you are attempting to find out the extent of an attacker's operations on your server. If pulling the plug is not an option, installing a stealthy backdoor may allow a better idea of what is going on, without alerting the attacker to your presence.
As far as most backdoors are concerned, the primary concern is maintaining a channel of communication and a method(s) for controlling the new host. Other major concerns include creating methods to transfer files and execute programs. Once these are established, you'll want as much control over those functions as possible. Often, it is important to ensure your access to the machine remains secret, or that the communication between your client and the server remains secret. Finally, you'll want to install some sort of access control, so that no one else may use the backdoor you worked so hard to get onto the system in the first place—particularly administrators and other hackers. Allowing others control really puts a damper on your access to the host.
There are several things to consider before you can choose a backdoor that suits your needs (listed in order of priority):
Your backdoor of choice must be able to run on the target host. It does not do you a whole lot of good to try installing a BackOrifice server (a Windows backdoor) onto your buddy's Linux-based server, now does it? If the backdoor requires a specialized client, you have to consider the operating system of the client machine. For example, not all Windows backdoors cater to the Unix-based attacker. Luckily, this is the exception rather than the rule. For some of the major backdoors, some kind souls have donated their time and their code to create interfaces tailored more specifically to a Unix environment.
For most Unix machines, the shell allows you all the control you could possibly desire, whereas on a Windows-based machine, the Command Line Interface (CLI) is hopelessly limited (for the most basic of functions it is barely passable). For anything more, you need a purpose-built interface allowing you to perform at least the major functions (file transfer, execution of files, access control), although for Windows, control over the Graphical User Interface (GUI) gives you the most functionality.
When trying to decide what features you absolutely need from your backdoor, consider the KISS (Keep It Simple Stupid) principle as a guideline. Less features and bloat means that you likely get a faster, more portable, and often more flexible backdoor. Using a tool such as Netcat (see Connecting to and Removing the VNC Backdoor) offers clear advantages in some cases (e.g., when you are trying to keep a low profile, when you have limited options for getting your backdoor on the system in the first place, or when you are dealing with multiple platforms).
You have to ask yourself about the likelihood the backdoor can be discovered on the server. Does it generate lots of user traffic? Is it monitored closely by an administrator? A lot of networks have machines that go unmonitored and unused. Will the source be easily tracked? If I do not need to worry too much about being discovered, then using a backdoor that takes full control over the GUI is not a big deal and certainly allows the greatest degree of control over a Windows-based OS, given that it is exactly what someone sitting in front of the server itself sees. I can tell you from experience how incredibly disconcerting it is to have control over your mouse taken from you and command windows popping open unexpectedly while doing something entirely unrelated—you have never seen a man lunge for the power cord so fast in your life.
Another consideration when choosing a backdoor is extensibility. Does the backdoor allow the behavior to be modified by plug-ins or scripts? Can you easily add useful or custom features? The ability to modify and script your backdoors becomes especially useful when coordinating many hosts at once, such as during penetration testing or when building and using a botnet. Distributed denial of service and spam also come to mind.
These considerations are by no means a complete list of things to look for but should offer you a starting point and a few ground rules for your own decision-making process.
Out of the several hundred or many more (perhaps thousands; who knows?) backdoors that have been written and distributed over the history of networked computing, I have chosen to discuss only several of the most popular tools and a few extra quick and dirty methods for establishing a backdoor with limited access. Some are not designed for use as backdoors, but were designed as fully featured remote administration tools and happen to make excellent backdoors for that very reason. Others were written specifically as tools of subversion and reflect that in their feature set. Some were included because they happen to be current at the time of this writing, and others left out due to lack of updates or support. (Netcat, of course, should be considered timeless.) This chapter is not intended to be a comprehensive document of all the features available in each tool; instead, it's intended to get new users up to speed on installing and using these tools in effective configurations as backdoors. Seasoned users should be able to consult this as a reference for ideas when confronted with a new or unfamiliar operating system.