Let me answer with a few observations, and comments. I will begin with the "whodunit" approach of aiding in determining who, what, when, where, and how.
- What - a file you found on your system
- When - what date was it found
- How - how was it uploaded
- Who - who uploaded it
You already know the file because you found it. Let's call this file: malicious.php. What you mention doing is determining "who" accessed this file, but you need to figure out how it was uploaded. Looking at the who accessed this file is the wrong approach. This is because attackers usually use multiple attack points. E.g., one system may scan you, another may compromise you, and yet another may access the system one compromised. So let's figure out the who first using deductive methods:
$ ls -ltha malicious.php
-rw-r--r-- 1 www-data www-data 0 Mar 27 10:59 malicious.php
In this instance, we see the file belongs to user www-data in group www-data. This does not mean an attacker uploaded it via http using post or get. There is nothing to stop someone from exploiting say telnet, uploading a file and performing a chown on the file.
ls -ltha --time=atime malicious.php
-rw-r--r-- 1 www-data www-data 0 Apr 27 10:09 malicious.php
ls -ltha --time=ctime malicious.php
-rw-r--r-- 1 www-data www-data 0 Apr 27 11:00 malicious.php
We can see the differences in timestamps here. If someone used say timestomp (Metasploit) MAC times can be changed. So we can deduce on the data above, that we are more or less within the 50 minute realm. Let's ensure that this user has never logged in, for that we can check wtmp, auth, ftp logs, etc. If this user has never logged in, we can then infer that this was not uploaded in any other fashion outside of via HTTP.
When - we reduced the timeframe to a degree to a 51 minute period. The logs I would look at would be error logs FIRST followed by access log. The reason for this is simple, at no point in time would an attacker know exactly how to get a file on your system. This means, there was a trial and error recon. This will be in your error logs appearing as a 404 or 403. I would search those first. Now let's further reduce the searching. A log analysis of visits will show what is normal versus what may be an anomaly. For example, if the base of traffic goes to say index.html remove all those instances, and look at the anomalies. One you determine this, you have then determined the How. This is completely separate from figuring out how they compomised your your code which would be a completely different question.