My server is compromised, and I try to get the open files of the malicious user, it says that the user does not have a UID , so it cannot find anything. I see there are processes which are running by that user but I cannot get the files opened by it.

  • 1
    If you haven't yet, I suggest you unplug the network cable – Fox May 2 '17 at 2:56
  • I did that, now I want to recover it. – Alex May 2 '17 at 2:58
  • 1
    @Alex No, don't try to recover. Reinstall. – Kusalananda May 3 '17 at 6:22
  • (1) How are you getting the username of the attacker? (ps?) (2) Exactly what command are you using that gives you this “the user does not have a UID” error? Please do not respond in comments; edit your question to make it clearer and more complete. – G-Man Says 'Reinstate Monica' May 8 '17 at 4:26

it says that the user does not have a UID

I can certainly agree with that. A user as defined by "malicious user running things on a server" does not have an UID, but that is because that user is a person who may (perhaps) run things as different UIDs on your machine (from now on I'll stick to the term "attacker").

Therefore the correct path is to try to figure out what path the attacker took to gain control of a process on your machine that could perform fork() and exec(). That is a pretty good starting point because, at the end of the day, a successful attack starts by gaining control (possibly in a very convoluted way) of a process that can do that. How the attacker manages to get to that point is what varies in the attack.

That said, the canon answer on what to do with a compromised server is to nuke it from orbit. It is not your computer anymore, and you cannot be sure on how much access the attacker achieved. Has the attacker achieved root privileges, then you may as well be connecting to a VM running on what once has been your server. Or you could even be dealing against a rootkit.

(Note: "nuke from orbit" means a "fresh install" by most people)

Back to the actual question:

why the username does not have a UID?

Or better, the implied one by the text of the question:

(how a process is running without an UID?)

The idea that a process is running without an UID is absurd. The kernel structure that maintains the existence of a process (actually the KSE) contains an UID field which must be populated (even if it is populated with rubbish in case of, say, a kernel bug). Therefore every process always has an UID.

What you are most likely dealing with is that the UID is not listed in /etc/passwd, which, although strange for a process, is no different from doing touch leet; chown 1337 leet (assuming that you do not have a user leet with that UID , that is). Pretty much all standard *nix tools work on UIDs as they would for usernames. i.e.

lsof -u username

is equivalent to

lsof -u `id -u username`


find . -user username

is also equivalent to

find . -user `id -u username`

Therefore back to the first quote (emphasis mine):

it says that the user does not have a UID

Whatever the it is in there, it is not a standard *nix tool. Or you're really more screwed than you believe, and are running inside some rather strange environment created by the attacker.

|improve this answer|||||

To find Ownerless files on your system you can run find / -nouser

You can also run find /sbin -mtime 1 to find any files which were modified within a day in /sbin directory.

|improve this answer|||||

Simply enough, the user and the binary may have been deleted from the system or root could have launched a process and changed the uid; be prepared that you might not find the binaries too.

At this point in time I would not boot with the compromised system, and would boot with a live distribution to analyze the file system. As grochmal says, tou might have compromised tools/binaries installed if there was a root compromise. The fact you have a binary of which you do not know the user points strongly to that.

That being said, I have seen a couple of system compromises, either with root escalation, and a simple user password compromise, were it seems a common trend to leave binaries running and then deleting them to complicate forensyc operations.

|improve this answer|||||

If you have processes running and you know their PID you can find what file descriptors are open with "ls -l /proc/PID/fd" where PID is the process of the dis process.

The problem is the process may open a file, read or write it and then close the fd. In that case nothing will tell you but @damansk idea of using find will help.

You could also strace the process and look to see what open() calls it makes.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.