Como É Possível Identificá Lo

Identifying Unknown Processes or Files on Linux

When a process shows up with no name, no clear PID mapping, or a suspiciously generic executable path, you already know the drill. I had a server last year where a process was consuming 40% CPU but the binary was just called 4a2f1b with no mounted filesystem reference. The inode was there, but the filename was gone — probably deleted after launch by whatever runtime dropped it. That scenario comes up more often than you'd think when dealing with containers, rootkits, or misconfigured services. Start with lsof. The command lsof -p <PID> will show every open file descriptor for that process. Even if the binary was deleted, the path often still appears with a (deleted) suffix. That alone can tell you whether the executable is from /usr/bin, a temp directory, or somewhere you didn't put it there. When I hit the 4a2f1b situation, lsof revealed the actual path was /tmp/.hidden/4a2f1b (deleted). The (deleted) flag was the first clue that something was running with no traceable origin. From there, check /proc/<PID>/maps. This file contains the memory mappings for the process. You'll see the executable path, shared libraries, and memory regions. If the process is trying to hide, the maps file might show a suspicious library path like /dev/shm/something.so or a mount namespace that doesn't match what you expect. I once found a process mapping an entire custom rootfs from a loopback device — the PID namespace looked normal, but the filesystem context was completely foreign.

strace -p <PID> -f is another useful tool. Running strace with the -f flag traces all child threads and forked processes. You'll see system calls in real time. If the process is opening suspicious sockets, writing to unexpected locations, or calling ptrace to attach to other processes, strace will show it immediately. This was how I confirmed the process from the earlier example was making outbound connections to an IP that wasn't in any firewall rules I had set up. The connections were using a non-standard port, and the socket calls showed up clearly in the trace. Sometimes you need to look at the process environment itself. /proc/<PID>/environ contains the full environment variables. Malicious or hidden processes often carry environment clues — custom paths, injection markers, or credentials that weren't present in the original shell. Read it with cat /proc/<PID>/environ | tr '\0' '\n'. I've seen processes launched from cron jobs with PATH variables pointing to directories that didn't exist on a normal system, which was the tell that something was overriding the standard environment. For network-related identification, ss -tlnp or netstat -tlnp will show listening sockets mapped to their owning process. If a process is bound to a port but doesn't show up in ps output, this helps correlate the two. I've dealt with services that were deliberately not listed in standard process tables due to container isolation, but the network socket was still visible and traceable back to a specific cgroup.

There are limitations to all of this. If the process is using process hiding techniques like unmounting its own filesystem or operating within a heavily restricted namespace, some of these methods may return incomplete data. In those cases, looking at cgroup information under /proc/<PID>/cgroup can help. It tells you which control group the process belongs to, which often reveals the container or service context that ps or ls won't show. On a system I managed with heavy container usage, the cgroup path was the only way to tell whether a process belonged to a legitimate service or was running outside of any known container. If the process has completely detached from the filesystem and you can't trace its origin, the most reliable approach is to look at auditd rules. Setting up a rule like auditctl -w /path/to/check -p x will log any execution attempts. It won't help with something already running, but it prevents the next occurrence from being invisible. I configured auditd on production servers after the earlier incident, and within a week it caught a second attempt to run an unlinked executable from /dev/shm. The audit log had the full command line and the parent process that spawned it. The main thing to remember is that no single method catches everything. The lsof approach works for most deleted binaries. Strace catches runtime behavior. Proc maps reveal memory layout. Audit logs prevent future blind spots. Using them together covers most of the gaps that any one tool leaves open.