How to Uncover Hidden Linux Processes with Unhide

While GNU/Linux is an extremely secure operating system, many people get lured into a false sense of security. They have the wrong idea that nothing can ever happen because they’re working from a secure environment. It’s true that very little malware exists for the Linux environment, but it’s still very possible that a Linux installation could be ultimately compromised. If nothing else, then considering the possibility of rootkits and other similar attacks is an important part of system administration. A rootkit refers to a set of tools a third party users after they gain access to a computer system they don’t rightly have access to. This kit can then be used to modify files without the knowledge of the rightful users. The unhide package provides the technology needed to quickly find such compromised software.

Unhide is in the repositories for most of the major Linux distributions. Use of a package manager command such as sudo apt-get install unhide is enough to force it to install on flavors of Debian and Ubuntu. Servers with GUI access could use the Synaptic Package Manager. Fedora and Arch distributions have pre-built versions of unhide for their own package management systems. Once unhide is installed, system administrators should be able to use it several different ways.

Method 1: Bruteforcing Process IDs

The most basic technique involves bruteforcing each process ID to make sure that none of them have been hidden from the user. Unless you have root access, type sudo unhide brute -d at the CLI prompt. The d option doubles the test to cut down on the number of false positives reported.

Output is extremely basic. After a copyright message, unhide will explain the checks that it performs. There will be a line stating:

and another stating:

If there isn’t any other output, then there’s no cause for concern. If the program’s brute subroutine finds anything, then it will report something like:

Found HIDDEN PID: 0000

The four zeros would be replaced with a valid number. If it merely reads that it’s a transitory process, then this might be a false positive. Feel free to run the test several times until it provides a clean result. If there’s further information, then it might warrant a follow-up check. Should you need a log you can use the -f switch to create a log file in the current directory. Newer versions of the program call this file unhide-linux.log, and it features plain text output.

Method 2: Comparing /proc and /bin/ps

You can instead direct unhide to compare the /bin/ps and /proc process lists to ensure that these two separate lists in the Unix file tree match. If there is something awry, then the program will report the unusual PID. Unix rules stipulate that running processes must present ID numbers in these two lists. Type sudo unhide proc -v to start the test. Tacking on v will put the program in verbose mode.

This method will return a prompt stating:

Should anything unusual occur, it would appear after this line of text.

Method 3: Combining the Proc and Procfs Techniques

If need be you can actually compare the /bin/ps and /proc Unix file tree lists while also also comparing all of the information from the /bin/ps list with the virtual procfs entries. This checks both the Unix file tree rules as well as procfs data. Type sudo unhide procall -v to perform this test, which might take quite some time as it has to scan all /proc stats as well as do several other tests. It’s an excellent way to make sure that everything on a server is copasetic.

Method 4: Comparing procfs Results with /bin/ps

The previous tests are too involved for most applications, but you could run the proc file system checks independently for some expedience. Type sudo unhide procfs -m, which will perform these checks plus several more checks provided by tacking on -m.

This is still a rather involved test, and may take a moment. It returns three separate lines of output:

Keep in mind that you can create a full log with any of these tests by adding -f to the command.

Method 5: Running a Quick Scan

If you merely need to run a quick scan without concerning yourself with in-depth checks, then merely type sudo unhide quick, which should run as quickly as the name suggests. This technique scans proc lists as well as the proc file system. It also runs a check that involves comparing information collected from /bin/ps with information provided by calls to system resources. This provides a single line of output, but unfortunately increases the risk of false positives. It’s useful to double-check after already reviewing previous results.

Output is as follows:

You may see several transitory processes come up after running this scan.

Method 6: Running a Reverse Scan

An excellent technique for sniffing out rootkits involves verification of all ps threads. If you run the ps command at a CLI prompt, then you can see a list of command run from a terminal. Reverse scanning verifies that each of the processor threads that ps images exhibit valid system calls and can be looked up in the procfs listing. This is a great way to ensure that a rootkit hasn’t killed off something. Simply type sudo unhide reverse to run this check. It should run extremely quickly. When it runs, the program should notify you that it’s looking for fake processes.

Method 7: Comparing /bin/ps with System Calls

Finally the most comprehensive check involves comparing all information from the /bin/ps listing with information taken from valid system calls. Type sudo unhide sys to start this test. It will more than likely take longer to run than the others. Since it provides so many different lines of output, you may wish to use the -f log-to-file command to make it easier to look back through everything it found.