O Detecting and Mitigating Backdoors

The first step in detecting a backdoor is to determine which processes should be running and which ports should be listening on your system. This can be obtained from the gold image baseline. Armed with that information, compare the data against the output of netstat and lsof. However, you must ensure that the baseline you are using to compare was captured on a pristine (uncompromised) system.

If you suspect a backdoor, start a packet capture of all packets going to and from the respective system. This will help to identify activity on the system and may assist in determining the existence of a backdoor and how it is being used.

The following commands can be used to enumerate open ports on the system, as well as match them to corresponding PIDs. Note that the scope is limited exclusively to the installed backdoor; in this case, netcat.

For netstat:

mail:~ # netstat -anp|grep 1337

For losf:

mail:~ # lsof -i -P |grep netcat netcat 4813 root 3u IPv4 87759610

The netcat example is quite easy to detect. Just about anytime netcat is listening on a port, it is not good. Often, backdoors are quite a bit more difficult to detect, particularly if you don't have adequate documentation about what should be running, listening, and loaded on your system.

If you don't have metrics regarding what should be running on a system, you'll need a more intensive backdoor detection method. Unless backdoors are hidden, as in a rootkit, they are definitely detectible. Depending on the methodology, you may have to spend a lot of time figuring out how they work. If a backdoor is detected on a system, complete the entire file integrity checking process to determine which files are associated with the backdoor (including the files used to make it start or listen on boot). Fortunately, there are tools and methodologies that may assist in this pursuit.

A best-case scenario would involve a situation where system administrators have comprehensive gold image baselines and documentation regarding the systems configuration in a pristine state. Using this as a starting point, they can easily identify what has changed on a system and begin an investigation from that point forward.

If there are no baseline images, then the first step is to identify (possibly through NSRL or Bit9 hash sets) the files that are known good and known bad. This will limit the scope of files that need to be analyzed, but it requires substantially more work than starting with comprehensive baselines.

Once you've acquired information about a backdoor, such as the port that it listens on, note each artifact and use it as a tool to get more information. For instance, if a backdoor listens on port 1337, you can identify the process associated with that port, as shown in the previous example with netstat and lsof. Furthermore, once you've identified processes, follow the chain between parent and child processes, as well as the associated users, until you can determine the root causes (users, processes, attack vectors, binaries, and so on) of events.

Once you know the name of the process that bound to the port, you can use lsof without any flags to find files that the particular process has open. This could be especially helpful in instances where a backdoor also performs some kind of logging—as in the case of a key logger.

Next, you can possibly locate the config file for a backdoor by doing a grep search for any file that contains 1337 or other identifiable strings. Once you find one of the files from a backdoor, you'll most likely find the remaining files in the same location.

Using forensic utilities in this effort can be especially helpful since these utilities include advanced searching capabilities that can simplify and speed up searches. Performing grep searches and organizing the results manually, without the help of forensic utilities, can be very labor intensive.

Performing string searches on binary files known to be associated with a backdoor can also yield valuable data. These searches commonly turn up the IP addresses of remote attackers, bragging info from attackers, possible configuration options, dependency file info, and so on. Quite a bit of useful data is written in ASCII and contained in binary files, but much of it may not be in plain text.

To find the dependencies associated with a backdoor, consider using ldd to determine any libraries it uses. This is especially helpful if some libraries were modified upon installation of a backdoor.

Of course, using a single utility like strace can uncover almost all of the data about how a backdoor operates. This will undoubtedly tell you more than you need to know about how the application functions, but you can then utilize that information to determine how to best use, modify, or disable it.

Popularity:

7

Simplicity:

9

Impact:

10

Risk Rating:

9

Perhaps the only thing worse than a backdoor is a hidden backdoor. For years, a steady evolution of malicious applications for UNIX systems has occurred. Rootkits consist of an advanced compilation of various malicious applications and combine many of their most useful features into a tidy package or kit.

Rootkit is actually a very descriptive name for this kind of software package. It assists attackers in maintaining root privileges. Rootkits originated in UNIX systems and were quickly ported to other nix variants. Since then, rootkits have become ubiquitous and have been created for other types of systems, such as Windows.

Linux rootkits can now be implemented in various ways, from modifying binaries and libraries to intercepting syscalls to installing kernel modules. Detecting them requires an in-depth understanding of how they operate and a sound detection methodology. Armed with this knowledge you then know where and how to look.

Depending on the type of rootkit and the hiding methods it employs, performing detection and mitigation can incorporate a combination of skill sets, including advanced systems administration, computer forensics, computer programming, and reverse engineering. This is certainly not a task for the light-hearted or easily discouraged.

Was this article helpful?

0 0
The Ultimate Computer Repair Guide

The Ultimate Computer Repair Guide

Read how to maintain and repair any desktop and laptop computer. This Ebook has articles with photos and videos that show detailed step by step pc repair and maintenance procedures. There are many links to online videos that explain how you can build, maintain, speed up, clean, and repair your computer yourself. Put the money that you were going to pay the PC Tech in your own pocket.

Get My Free Ebook


Post a comment