This is not a pure science but hopefully I can offer some assistance.
The NTUSER.DAT stores the contents, size, and location of every explorer window opened in Windows XP. This means that if this person had copied said files to another location, and then opened that location to check the files were correctly copied, there will be an entry in the NTUSER.DAT showing the location of the relevant storage media and a list of all files contained therein.
The following file details will be listed - Filename, size, created, modified, accessed, long filename. If these properties match the suspect files then you have to evaluate if this is worth pursuing further - applying for a search and seize order and such.
This information is found in 'Software\Microsoft\Windows\Shell\Bags. The easiest way to parse out this information is to use MiTeC Windows Registry Analyzer (Google it), load in the NTUSER.DAT file and then use the Spy & Analyze option to retrieve all ShellBags entries.
This has worked for me several times in the past. Its also good if a user has wiped the contents of a folder but left the registry in tact.
You can also use this method on restore points throughout the computer's 'history'.
keydet89, based on your last post, is it not true that if you see that there are, lets say 100 files, showing a last accessed date from the same day and the time from 100 PM to 102 PM that you could say that the files were copied or moved to another location?
In the instances I've seen this, it's most often been the result of an AV scan. However, with no other information, seeing a 100 files, all with their last accessed times within a very small window…simply means that I have 100 files all with their last accessed times in a very small window. Incident responders and forensic analysts should not speculate to make the data fit their theory.
As for the USB device, I thought that you could only see the first instance of when the USB device was attached in the registry.
Not sure why you thought that…sorry.
Thanks for correcting me on the USB date modification date & time. For some reason I was under the same impression as noahb1868. oops
Incident responders and forensic analysts should not speculate to make the data fit their theory.
I’m not sure I agree with you here – well at least not necessarily… It all depends on the context and rules that you have to function within, and perhaps most importantly what your role is. Are you an incident responder & forensic analyst, or an investigator?
If you are a responder or an analyst and are trying to go from evidence to necessary cause of that evidence being there, you are absolutely correct (i.e. you want to claim that the altered access times etc. mean that the files were copied).
On the other hand if you are an investigator creating hypotheses that might help explain the data, which is (sort of) what is being done in this scenario, then I’m not sure I agree. I think the principal role of an investigator is to do just that to come up with possible scenarios that are consistent with and explanatory of the evidence that you find.
…Although at the moment we're just discussing what evidence might be relevant to answering the question of whether the files were copied out to an external device. On that question, depending on the OS and whether auditing was enabled and properly configured, security event logs would show when files or folders were accessed by the user - but then this is more a server related approach.
Again, access just means access, but if the relevant files or folders were accessed at the same time as the USB was used, same possible conclusions…
I have tried using WRA for analysing shellbags but I did not get any result. The report is blank.
Is there an explanation on why? How can it be possible that the user did not open any folders?
Any other tools beside WRA to analyse shellbags?
Thanks for correcting me on the USB date modification date & time. For some reason I was under the same impression as noahb1868. oops
Incident responders and forensic analysts should not speculate to make the data fit their theory.
On the other hand if you are an investigator creating hypotheses that might help explain the data, which is (sort of) what is being done in this scenario, then I’m not sure I agree. I think the principal role of an investigator is to do just that to come up with possible scenarios that are consistent with and explanatory of the evidence that you find.
Correlation is not causation, as the saying goes. Over 30 processes are started when Windows starts, most of which continue to work in the background whether the user is active or not. Add antimalware programs and the like and you have a very dynamic environment in which observations don't always have obvious explanations.
Against this backdrop we are often asked to answer the question, "What did the user do?" and to do that we may need to draw inferences from nothing more than circumstantial evidence. As long as we don't confuse plausibility with certainty, we're ok. But I have worked on cases where a party was able to get an ex parte order on the basis of the unrebuttable testimony of an "expert" who claimed that the presence of A always proved the existence of B with the result that investors in the other party got skittish and pulled out their investments. The expert's theory was, eventually, discredited but not before it had caused significant financial harm to the party.
I’m not sure I agree with you here – well at least not necessarily… It all depends on the context and rules that you have to function within, and perhaps most importantly what your role is. Are you an incident responder & forensic analyst, or an investigator?
I'm an incident responder, and I do forensic analysis.
If you are a responder or an analyst and are trying to go from evidence to necessary cause of that evidence being there, you are absolutely correct (i.e. you want to claim that the altered access times etc. mean that the files were copied).
On the other hand if you are an investigator creating hypotheses that might help explain the data, which is (sort of) what is being done in this scenario, then I’m not sure I agree. I think the principal role of an investigator is to do just that to come up with possible scenarios that are consistent with and explanatory of the evidence that you find.
Coming up with…and then proving, through data…possible scenarios is part of what we do. This can be done through additional analysis, correlating data, or even testing.
However, speculating in the absence of data is simply laziness and shoddy work.
I was involved in an engagement where systems were found to be initiating connects from the customer's infrastructure out to a system on the Internet. The executable responsible for connections was no obfuscated and the import table could be easily examined. At one point, the customer's IT staff started talking about the executable performing keystroke logging…but there were no indications to support this speculation.
…Although at the moment we're just discussing what evidence might be relevant to answering the question of whether the files were copied out to an external device. On that question, depending on the OS and whether auditing was enabled and properly configured, security event logs would show when files or folders were accessed by the user - but then this is more a server related approach.
If all you have is an image of a system, and not the media to which you suspect files had been copied, I would suggest that it is not possible to tell which files had been copied off of the system.
For Windows Event Logs to demonstrate access, one would have to enable File and Object Access auditing, *then* enable the necessary settings on the files themselves. This can be done on Windows 2000, XP and beyond, but many times isn't.
Again, access just means access, but if the relevant files or folders were accessed at the same time as the USB was used, same possible conclusions…
My point exactly. If several files had last access times just prior to a removable storage device being removed from the system, then you have to facts that may not necessarily be related.
Case in point…during an intrusion response last year, I found that the ftp.exe file on a system had last been accessed during the timeframe that an intruder was on the system (intruder had shell-level access, and created their own account, so a good deal of activity was recorded in the Registry). Speculation would lead one to believe that the intruder had made use of FTP for some reason. However, further examination of the system image revealed that all of the files within that directory had their last access times modified to within a relatively small time window, and further analysis revealed that an antivirus scan had been run.
As in many instances, speculation in that case would've provided incorrect information and sent responders down a rabbit hole.
Again, access just means access, but if the relevant files or folders were accessed at the same time as the USB was used, same possible conclusions…
My point exactly. If several files had last access times just prior to a removable storage device being removed from the system, then you have to facts that may not necessarily be related.
Case in point…during an intrusion response last year, I found that the ftp.exe file on a system had last been accessed during the timeframe that an intruder was on the system (intruder had shell-level access, and created their own account, so a good deal of activity was recorded in the Registry). Speculation would lead one to believe that the intruder had made use of FTP for some reason. However, further examination of the system image revealed that all of the files within that directory had their last access times modified to within a relatively small time window, and further analysis revealed that an antivirus scan had been run.
As in many instances, speculation in that case would've provided incorrect information and sent responders down a rabbit hole.
Not necessarily a rabbit hole. Just because AV software was run during said timeframe does not necessarily indicate that ftp.exe wasn't accessed by the intruder, either. If you're a forensic analyst working for the prosecuter in a criminal case, this would definately be an avenue you'd want to pursue and a fact you'd want to present. And I think that's erowe's point - sometimes, based on your job, you need to generate all possible leads from the least evidence available. But it still doesn't prove fact - just gives you some investigative ideas.
Jeff
Jeff,
Not necessarily a rabbit hole. Just because AV software was run during said timeframe does not necessarily indicate that ftp.exe wasn't accessed by the intruder, either. If you're a forensic analyst working for the prosecuter in a criminal case, this would definately be an avenue you'd want to pursue and a fact you'd want to present. And I think that's erowe's point - sometimes, based on your job, you need to generate all possible leads from the least evidence available. But it still doesn't prove fact - just gives you some investigative ideas.
Sorry, but that makes no sense to me at all.
In the instance I described, I was able to prove, through Registry analysis, AV log analysis, and then going back and asking the sysadmin, that the AV scan had been run. The last access time on the ftp.exe file corresponded to the scan.
In the absence of, say, an FTP script file (which we did not find), how would we go about proving that an intruder had used ftp.exe? How would you suggest pursuing the "investigative lead"?
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.
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.
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.
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.
As an avenue of investigation, perhaps, but I certainly wouldn't feel calling this other than idle speculation in the absence of any other evidence to support it. In my own experience, Occam's Razor has proven to be an effective strategy for weighing evidence almost across the board and that is especially important when your report could lead to civil or legal action.
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 don't think that anyone was saying that you wouldn't want to look further however, the point is that you have a simple explanation for all of the facts as you know them.
I was involved in a case where the opposing expert was able to document that certain Outlook attachments were present in temporary space whereas other attachments, associated with messages in the same time frame were not. On this basis, he concluded that those attachments which were not present had been "surgically deleted" as part of a deliberate attempt to destroy evidence. His line of thinking was why would some attachments be there and not others unless they had been deliberately removed.
This was a motion hearing and in rebuttal, I remarked that the management of temporary space was up to the application for which it was created and the simplest explanation was that Outlook had deleted some of the attachments and not others. Luckily, for my client, the hearing was adjourned without conclusion.
Going back to the office I researched the behavior of Outlook and attachments and found what was really a needle in a haystack, namely, a single bug report on the Microsoft web site whereby attachments in Outlook e-mail were not deleted after the email was closed. It turned out that the default is to delete attachments but if the native application which opened the attachment (e.g. Adobe Acrobat) is not closed before the message is closed, Outlook loses the handle and can't delete it. The abnormal behavior was the persistence of the attachments, not their deletion.
The other expert's opinion was plausible but also potentially very damaging to my client. My explantion was correct but at the time there was but one obscure document by which to establish its correctness. If I had not found that document, our arguments might have made it to a jury where his claim would have been prejudicial, at the very least. For reasons such as this I am extremely careful not to assert what I cannot document to a reasonable degree of certainty.
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.
In science it is the case that a theory cannot be accepted as a theory unless there exists some process or method whereby, if the output of that process or method were true, the theory would be disproved. As an example, take the theory of gravitational attraction between two objects. If I could let go of a ball in the middle of the air and, barring any unique properties of the ball, it would stay put that would disprove the theory. A consequence of this is that you cannot prove a negative.
Some experts in computer forensics have argued that we should be no less rigid in espousing our opinion than scientists, i.e., we should not be advancing theories for which there does not exist the possibility that the theory could be disproved if something else were true.
In your example, it is plausible that the events happened exactly as you suggested. But there is no way that this can be disproved since nobody, insofar as I am aware, logs files that aren't ftp'd.
I, for one, would be hard pressed to even suggest this as a plausible hypothesis since it is prejudicial and cannot be refuted (or affirmed).