To find the immediate culprit is most likely a minor forensics exercise.

Check your access log and look at the queries that were active at 11:00 on Aug 20 (assuming that no diddling was done on the file after it was placed there).

If your logs are Apache and you have the 'time to execute' in your logs, you can subtract the time to execute from the log time to find your start time, otherwise you could probably get a pretty good bound by starting at 11:00 and expanding the search around that time. Also check your error logs for warnings or errors around that time.

Now, if your scripts directory can be written to by any other web server running on that box (why would 'nobody' be able to write to your scripts directory?), then you have much larger problems. Check your scripts directory to see if it is open for writing. The web server should never (there is an absolute...) be able to write to a directory containing trusted content (including scripts and html pages) unless you are very certain that this is the correct way to implement some solution (... and there is the hedging statement). There is major risk allowing the web server to have write access to anything except the most distrusted areas in your environment (as you have found).

If you have configured your directory to be writable by the web server, fix it. Now. If your vendor has set it up that way, or even worse, requires it to be set up that way, move to a new vendor, quickly. chmod and chown may help in this regard.

Security is a mindset, not just a checklist that one goes through to be able to say "Yep, secure". Vigilance in monitoring your logs, distrust of anything from outside (and sometimes even inside) of your program, knowing your environment, and considering the attacker's point of view in each and every block of code are just a start to good security.

Thanks for your time.

However, the file was written to document root directory and not the cgi-bin.

If you are running php scripts from that directory, it is a scripting directory. Additionally, the same statement can be made about any directory that a browser can access directly through the web server. Basically, if the web server can write anywhere you don't explicitly tell it to, it is a problem.

--MidLifeXis

Most virtual host setups provide well-known “convenience” goodies ... Plesk and so-on ... which are intended for use by the site administrators, but which are therefore well-known to others.   Is there a non-secure, ftp, service process running?   Is it possible, literally, to log-in using sh?

Certainly begin by making the entire directory-structure read-only.   A web server never has any plausible reason whatever to be able to write to whatever it is reading.

The first thing that I do with any virtual server is to wipe the sucker completely clean and to install a bare-bones OS onto it, completely eliminating things like Plesk which I don’t need anyway.   Every time that I failed to do this is a time that I came to regret.

I appreciate everyone's help.

I was considering making the whole directory structure read-only. I will readup up in the material suggested.

I have no doubt that the source of that file came from "out-of-band." Maybe even an anonymous shell access. The user came in as "nobody" but still was able to get to that file location and to put something there ... and that also means, perhaps to replace something else there. If file and directory permissions would have prevented access from "nobody," then immediately you know that someone was covering their tracks.