I am analyzing a disk image in which I have discovered a huge amount of activity all on one day. I would like to know if anyone has encountered this or if anyone has any insight in to what activity would create this.
There are about 200,000 rows in the timeline but 110,000 all occur in a six hour span on the same day. Here is some additional information
1) the image is windows XP NTFS partition
2) the six hour period has entries every second
3) all folders seem to be included from /windows, /documents and settings, /Program Files, etc.
4) the majority of all entries are ..c. entries
5) however there are a number of .a.. entries especially on dll files
My assumption is that the user has performed a full copy of the C/ drive to another drive such as a USB drive. The .a.. are operations in which the file was unable to be copied because it was in use.
However when reading the http//
Are there any other activities that would cause this behavior? Service Pack Upgrade perhaps? But I would only expect C/windows not the entire drive.
Thanks for your insights.
If anyone has any articles on macb analysis that would also really help.
Greetings,
Which timestamp(s) were modified? You imply that the Created timestamp is what changed, but more details would be very helpful.
Any chance everything was copied *to* the partition you're examining rather than *from* it?
-David
Here are a few examples entries. The vast majority all have the ..c. attribute modified such as the ones listed below.
Fri Dec 21 2010 121829
7168 ..c. r/rrwxrwxrwx 0 0 10876-128-3 C/WINDOWS/system32/dllcache/recover.exe
3338 ..c. r/rrwxrwxrwx 0 0 10878-128-3 C/WINDOWS/system32/dllcache/redir.exe
3584 ..c. r/rrwxrwxrwx 0 0 10883-128-3 C/WINDOWS/system32/dllcache/regedt32.exe
33792 ..c. r/rrwxrwxrwx 0 0 10885-128-3 C/WINDOWS/system32/dllcache/regini.exe
Fri Dec 21 2010 121847
19712 ..c. r/rrwxrwxrwx 0 0 29468-128-3 C/WINDOWS/system32/drivers/partmgr.sys
3626112 ..c. r/rrwxrwxrwx 0 0 4429-128-3 C/WINDOWS/system32/drivers/NETw5x32.sys
43 .a.. r/rrwxrwxrwx 0 0 45747-128-1 C/Documents and Settings/johnd/Local Settings/Temporary Internet Files/Content.IE5/M6TYHOTW/JGCJKtGmxvq[1].gif
292 .a.. r/rrwxrwxrwx 0 0 45755-128-1 C/Documents and Settings/johnd/Local Settings/Temporary Internet Files/Content.IE5/37GNI5S1/AA4mSyZRGOi[1].png
As for whether everything was copied TO rather than FROM the partition it is possible but that doesn't make much sense as that would mean that the entire system folder was copied back to the laptop. Would this happen when someone did a backup restore?
Hi,
What testing have you done to look at what happens when you backup something, or what testing have you done on mass files to see what causes possible differences.
Patches/Service packs?
@armresl - I have not done a lot of testing as I was hoping on getting "possible scenarios" / leads here before I performed further testing. Plus we are not aware of what tools the user would have used so its hard to replicate the exact tool.
I guess my question is, "Is it possible that a copy of the entire drive occurred to a separate drive? Or is this behavior (tons of ..c. entries) found in other scenarios?"
Greetings,
Yes, it is possible.
It is also possible that much of the drive was copied *to* this drive.
Have you looked at what tools are installed? Would any of them cause this sort of behavior?
Have you confirmed your results with another tool?
-David
Thanks Kovac.
I am going to investigate the installed tools on the drive. Good idea.
I have been trying to confirm my results with PTK however the top menu bar is missing once I add an image. I have opened a separate thread on this. PTK Menu Missing
I was doing some further research and I discovered that the ..c. entry in NTFS actually refers to the updating of the MFT entry.
Does anyone know if when a file is modified or accessed the MFT table is updated (in ntfs)?
The C entry could be consistent with a backup. The archive bit being turned off.
That would depend on what files have the C entry are listed. But I think the most telling would be an access to a backup program at the start of the long list of MFT entry updates.
I guess a wiping program that messes with timestamps to hide activity could also be a plausible theory.
Possibly a disk defrag? That would update the MFT's data run entries.
I would rate any sort of file copy as low probability, as you'd likely see Modified or Created timestamps as well. The exception being that those timestamps could be listed later, and thus would not show as here. But, with all the MFT Modified updated timestamps, you'd think more, at least a few, would have M or B timestamps.
Just random ideas off the top of my head.