We could always expand on the for loop in step 6 if we needed to in order to hone the focus of the search further. This is largely dependent upon what information we were given to start. For example, if an end user comes to us and tells us that there are some strange files in their home directory on the corporate web server, we could increase the focus of the find command by running it against the user's home directory instead of the root directory. That way, we can see all the binary files in that particular user's home directory. Any information we can gather prior to the discovery phase will only help us during this phase of the methodology. Sometimes asking the right questions saves hours of hunting. The which command can also help us in the discovery phase of our methodology by showing us the location of a given command. In the event one of the commands, Bash, for example, is linked to an alternative binary with the same name, the which command will show us the path name and file tied to that alias or command. If we run $ which bash, for example, and see /temp/maliciousBash instead of /bin/bash, something is definitely wrong. This is an extreme example, but it should highlight the point I'm trying to make.

Even when reviewing running processes, we can narrow down our focus by filtering out users we don't care about. If you suspect a complete compromise of the host, reviewing all processes running under the context of the root user might be a good place to start hunting for associated binaries. We can easily do this using the -U and -u options to the ps command. Alternatively, we can use the top command and all of its powerful functionality to interrogate the running processes on the host. Another area to look for information is crontab. Issuing a simple cat /etc/crontab can reveal a plethora of information and when cron jobs are scheduled to run. As a penetration tester, using cron jobs to run my own code was one way to elevate privileges, assuming a misconfigured cron job was present with misconfigured permissions. I don't really see this attack vector too often anymore, but that doesn't mean a malicious user couldn't still abuse cron to replicate their malware and hide it using an inconspicuous name for a cron job.