You proved that an AV scan occurred, thus modifying the Last Accessed timestamp of the ftp.exe, but what if this intruder had opened an FTP connection during the window in which he was connected but prior to the start of the AV scan or just prior to when the AV engine touched that particular file? Then you really haven't proven that he didn't create an outbound FTP connection, rather you presented some circumstantial evidence which might suggest otherwise.
This conversation has degenerated in to speculation based on a timestamp that is unreliable to begin with. Before you start discussing proof, you need to realize that we have no such thing as proof in this field. Proof is an absolute solution or explanation to a problem - and we have no such thing. All we have is circumstance, often times in mountainous piles, which is commonly presented as proof, measured in certainty, confidence, and probability and discussed in terms of risk.
So, why not try to address this in a more scientific method?
FACT
A file had an access time updated during the time an attacker was operating on a computer.
BACKGROUND
Q Under what conditions is an access time updated?
A An access time is updated when a file is opened for reading, specifically a file's attributes.
Q Does a file access time being updated indicate execution?
A NO. It simply indicates that the file's attributes were accessed.
Example the 'touch' command would update an access time, as would an A/V scan and many other utilities.
Conclusion There are many plausible explanations for a file's access times being modified.
Our job Determine what is most plausible and present your conclusions with supporting documentation.
Assuming a Windows XP system
In the case of executable being executed under normal circumstances, what artifacts could we expect to find?
1) A prefetch file would be created
2) Depending upon method of execution we could expect to find artifacts in the registry.
3) Memory analysis would show that it had been executed
4) Other sources yet to be discovered or mentioned.
Variables (Factors and Forces).
1) Intruder privileges - with full administrative privileges, the attacker effectively has their hand on the clock's dial, and do what they please.
2) System operation - Antivirus scans, backups, other scheduled tasks that have the potential to alter an access time.
3) User activity - a user logged in to the system at the time could have done something to update the access time.
4) Intruder activity - The attacker used ftp.exe or had a tool capable of modifying timestamps on the system.
5) Unknown possibility - something that hasn't been thought of or discovered that has the possibility to modify access times.
So, let's start processing this
What we know
- An antivirus scan was being run when the file access time was updated.
- The sysadmin confirmed this.
- There are no artifacts present in the registry suggesting execution.
Given the data presented, what is your reasonable belief? More important, what would someone else, a lay person (read decision maker) in particular, be likely to believe?
That an access time had been updated by
A) a normal system operation (A/V scan)
B) The attacker had executed the file and exfiltrated data.
Are these the only possibilities? No they are not. However, absent any data to refute that A is the most likely answer, what would someone be likely to believe?
For B to be the more likely answer in this case what must be present?
1) Network or other logs during the time of compromise suggesting ftp connections.
2) Artifacts suggesting execution of ftp.exe
If this were a case where there was a potential leak of classified data, I can guarantee you that I would include this possibility in my report and that we'd follow this lead up with checking outbound connection logs from firewalls or IDS/IPS. The customer would demand it, and rightfully so.
I would hope you would have explored this possibility before presenting any sort of report other than a SITREP.
Absent any other logs, I wouldn't be able to definitively say that no data had been ex-filtrated, due to the AV scan corrupting potentially inculpatory evidence. Then again, I try never to state anything definitively, if I can help it. The fact that the file had been accessed during a timeframe when the intruder was present on the system would be mentioned in the report - as would the fact that an AV scan occurred at the same time. If I found no corroborating evidence to indicate that the intruder created an outbound FTP connection, I'd state as much in my report, as well.
That's right, you wouldn't be able to say that no data had been exfiltrated. What you are effectively stating is that the updated access time, is a non-issue. That a file had merely had an access time updated during the time of compromise indicates that an access time was updated during the time of compromise, and nothing more. To suggest that it implies anything else without data to affirm or refute is biasing the decision making process. Would you also include the fact that net.exe had it's A-time updated, suggesting that an attacker *could have* executed it in an effort to enumerate the network. Suggesting what *could have* happened or *what if* in a report is something better left out as it introduces bias and conjecture unless you have data to support that conclusion. Showing what you believe to be the most plausible reason for an occurrence is what needs to be the focus instead, and this is accomplished by providing as many plausible explanations as is reasonable that makes sense, and showing that you believe your conclusion to be the correct one, because there is not enough data to suggest the other explanations are more plausible. The focus should also be on explaining what you did see versus what you didn't see.
To answer the original question, no, there is no definitive way to determine a file had been copied to an external drive absent that drive, but there are some good suggestions in the thread for avenues to explore.
Without the source, and the suspected external output for hash analysis, all you can do is speculate.
Several things will change the last accessed times of files. AV scans are one of them. However, copying files from one disk to another will do the same thing on the target disk. i.e. from a server drive to a workstation drive or vice versa.
Or from one drive to another on the same workstation.
Also, if you restore files from a backup to a new location, the folders will be created new on the new location and the MAC times will reflect that for the folder, but not the files within those folders.