Hello Reader,
I'm going to change tracks this week and focus on a deeper understanding of the USNJrnl and its associated artifacts to prove usage from our challenge two weeks ago. To prepare for this series I want to take a bit to explain what each of the artifacts we rely on for proof of usage were created for. When we are complete I hope you will look at your cases in a different way.
Today we are going to talk about the USNJrnl. The USN Jrnl or Update Sequence Number Journal aka the Change Journal was first introduced in Windows 2000 but didn't get enabled by default until Windows Vista (that I know of, please leave a comment if you have evidence of other default states/os's). I have seen it enabled for EFS encrypted drives on XP but I can't say if that's a default setting.The concept of the change journal was simple, many programs need to know when files are changed so they can be backed up, compressed, scanned, replicated, etc...
Prior to the change journal a developer would have to register hooks or shims into the operating system for all reads and writes to be able to be notified that a file is being created/modified/deleted and to process it. The Change Journal gave the developer a central api to monitor that covered all subscribing functions and prevented a lot of unnecessary overhead. You can read more about the basics of the Change Journal here on wikipedia. The original announcement of it was made in September 1999 and can be found here its interesting that it took as long as it did for it to be enabled by default. You can see that it was being marketed to developers as a way to centrally monitor file system changes and improve performance.
The current change journal development documents are here and if you relying on change journal evidence in your cases you should be familiar with the use case scenario because things are not as black and white as they appear. What do I mean by that? In our testing we've found that a file left open overnight and accessed at different times will create multiple USN open/close/delete events. You cannot rely on the file open and file close times of a file to determine total time of access, it may only be showing you the times of activity against a file that was open the entire time. In addition we've found file close/file delete being used to close a file handle but not to delete the file itself.
I'm going to into more detail of how individual Change Journal operations work and get logged as we move forward so I don't want to get ahead of myself. So in summary remember that the Change Journal keeps track of file system changes for the benefit of those subscribing services. If you are unsure of a pattern of records your seeing the best thing you can do is build a virtual machine and try to recreate those actions to validate your assumptions. The Change Journal is not as simple as we all though it to be! Tomorrow I'm going to continue talking about Usage artifacts and then go into depth on the Change Journal and the rest of them.
I'm going to change tracks this week and focus on a deeper understanding of the USNJrnl and its associated artifacts to prove usage from our challenge two weeks ago. To prepare for this series I want to take a bit to explain what each of the artifacts we rely on for proof of usage were created for. When we are complete I hope you will look at your cases in a different way.
Today we are going to talk about the USNJrnl. The USN Jrnl or Update Sequence Number Journal aka the Change Journal was first introduced in Windows 2000 but didn't get enabled by default until Windows Vista (that I know of, please leave a comment if you have evidence of other default states/os's). I have seen it enabled for EFS encrypted drives on XP but I can't say if that's a default setting.The concept of the change journal was simple, many programs need to know when files are changed so they can be backed up, compressed, scanned, replicated, etc...
Prior to the change journal a developer would have to register hooks or shims into the operating system for all reads and writes to be able to be notified that a file is being created/modified/deleted and to process it. The Change Journal gave the developer a central api to monitor that covered all subscribing functions and prevented a lot of unnecessary overhead. You can read more about the basics of the Change Journal here on wikipedia. The original announcement of it was made in September 1999 and can be found here its interesting that it took as long as it did for it to be enabled by default. You can see that it was being marketed to developers as a way to centrally monitor file system changes and improve performance.
The current change journal development documents are here and if you relying on change journal evidence in your cases you should be familiar with the use case scenario because things are not as black and white as they appear. What do I mean by that? In our testing we've found that a file left open overnight and accessed at different times will create multiple USN open/close/delete events. You cannot rely on the file open and file close times of a file to determine total time of access, it may only be showing you the times of activity against a file that was open the entire time. In addition we've found file close/file delete being used to close a file handle but not to delete the file itself.
I'm going to into more detail of how individual Change Journal operations work and get logged as we move forward so I don't want to get ahead of myself. So in summary remember that the Change Journal keeps track of file system changes for the benefit of those subscribing services. If you are unsure of a pattern of records your seeing the best thing you can do is build a virtual machine and try to recreate those actions to validate your assumptions. The Change Journal is not as simple as we all though it to be! Tomorrow I'm going to continue talking about Usage artifacts and then go into depth on the Change Journal and the rest of them.
