Menu > Articles de la revue de presse : - l'ensemble [tous | francophone] - par mots clé [tous] - par site [tous] - le tagwall [voir] - Top bi-hebdo de la revue de presse [Voir]

---

S'abonner au fil RSS global de la revue de presse

---

Présentation : I recently conducted some testing of different actions on a Windows 7 system, with the specific purpose of identifying artifacts within the file system in this case, the MFT and the USN change journal , particularly within individual records. I wanted to take a look at the effects of different actions to see what they look like within the individual records, as well as within the USN change journal, in hopes that things would pop out that could be used during forensic exams. Once I completed my testing, I decided to share what I'd done and what I'd found, in hopes that others might find it useful. Testing Platform 32-bit Windows 7 Ultimate VM running in Virtual Box. Tools My own custom stuff. I updated the MFT parser included with WFA 4 e, and used usnj.pl to parse the USN Change Journal, and parse.pl to translate the output of the change journal parser into a timeline. This page at MS identifies that USN record v2 structure, and the reason codes, used by usnj.pl. Methodology I started by writing down and outlining all of the tests that I wanted to perform. I had a total of 5 tests that I wanted to run in order to see what the effects of each individual action was on the MFT, and individual records within the MFT. I picked 5 different files within the VM to use in each test, respectively. Once that was done, I added the VM to FTK Imager as an evidence item and extracted the MFT this was my before sample. Then, I launched the VM, performed all of the tests, logged out and shut down the VM, and extracted the MFT my after sample and the USN change journal. All testing occurred on 17 July 2014. In all of the tests, I've changed the font color for items of interest to red. Test 1 - Renaming a file This was a simple test, but something I hadn't specifically looked at before. All I did with this one was open a command prompt, change to the directory in question, and issued the command, ren eula.txt eula30.txt . Here's the record details from before the test was run 44657 FILE Seq 3 Links 1 FILE , BASE RECORD . tools Eula.txt M Fri Nov 8 15 17 17 2013 Z A Fri Jul 28 14 32 44 2006 Z C Fri Nov 8 15 17 17 2013 Z B Fri Jul 28 14 32 44 2006 Z FN Eula.txt Parent Ref 44361 32 Namespace 3 M Fri Nov 8 15 17 17 2013 Z A Fri Nov 8 15 17 17 2013 Z C Fri Nov 8 15 17 17 2013 Z B Fri Nov 8 15 17 17 2013 Z ...and here are the record details after the test 44657 FILE Seq 3 Links 1 FILE , BASE RECORD . tools eula_30.txt M Fri Nov 8 15 17 17 2013 Z A Fri Jul 28 14 32 44 2006 Z C Thu Jul 17 20 38 52 2014 Z B Fri Jul 28 14 32 44 2006 Z FN eula_30.txt Parent Ref 44361 32 Namespace 3 M Fri Nov 8 15 17 17 2013 Z A Fri Jul 28 14 32 44 2006 Z C Fri Nov 8 15 17 17 2013 Z B Fri Jul 28 14 32 44 2006 Z Again, this was an atomic action that is to say, all I did with respect to this file was run the ren command. I honestly have no idea why the last accessed A and creation B dates from the STANDARD_INFORMATION attribute would be copied into the corresponding time stamps of the FILE_NAME attribute for a rename operation. However, notice that very little else about the record changed the record number from the DWORD at offset 0x2C within the record header , the sequence number, and the parent file reference number remained the same, which is to be expected. Here are the changes recorded in the USN change journal eula_30.txt Rename_New_Name FileRef 44657 3 ParentRef 44361 32 eula_30.txt Rename_New_Name,Close FileRef 44657 3 ParentRef 44361 32 Eula.txt Rename_Old_Name FileRef 44657 3 ParentRef 44361 32 Now, these changes are not in the specific order in which they occurred...they're listed in a timeline, so they occurred within the same second. But it is interesting that there is rename_old_name and rename_new_name identifiers for the actions that took place. Perhaps because a good deal of the analysis work that I do comes from corporate environments, I've been seeing a lot of Windows 7 systems with VSCs disabled in the Registry as such, I haven't had access to an older version of the MFT via a VSC in order to compare record contents, on a per-record basis. By incorporating the USN change journal into my analysis, I can get some additional context with respect to what I'm seeing. The use of the USN change journal can also be useful in identifying activity that occurs during a malware infection. For example, in some cases, malware may create a downloader, use that to download another bit of malware, and then delete the original downloader. The USN change journal can help you identify that activity, even if the MFT record for the original downloader has been reused and overwritten. Test 2 - Adding an ADS to a file For this test, I added an ADS to a file by typing echo This is an ADS procmon.chm ads.txt at the command prompt. Now, this file is the ProcMon help file that is included when you download the ProcMon archive from SysInternals, and as such, it already had a Zone.Identifier ADS associated with the file. The before record 44401 FILE Seq 11 Links 1 FILE , BASE RECORD . tools procmon.chm M Fri Nov 8 15 17 17 2013 Z A Mon Nov 28 16 46 42 2011 Z C Fri Nov 8 15 17 17 2013 Z B Mon Nov 28 16 46 42 2011 Z FN procmon.chm Parent Ref 44361 32 Namespace 3 M Fri Nov 8 15 17 16 2013 Z A Fri Nov 8 15 17 16 2013 Z C Fri Nov 8 15 17 16 2013 Z B Fri Nov 8 15 17 16 2013 Z ADS Zone.Identifier ...and the after record 44401 FILE Seq 11 Links 1 FILE , BASE RECORD . tools procmon.chm M Thu Jul 17 20 39 22 2014 Z A Mon Nov 28 16 46 42 2011 Z C Thu Jul 17 20 39 22 2014 Z B Mon Nov 28 16 46 42 2011 Z FN procmon.chm Parent Ref 44361 32 Namespace 3 M Fri Nov 8 15 17 16 2013 Z A Fri Nov 8 15 17 16 2013 Z C Fri Nov 8 15 17 16 2013 Z B Fri Nov 8 15 17 16 2013 Z ADS ads.txt ADS Zone.Identifier In this case, you'll notice that only the M modified and C MFT entry change times in the STANDARD_INFORMATION attribute have changed. I would expect that the C entry changed time stamp would change, as the addition of an ADS constitutes a change to the MFT record itself, but the M last modified time stamp changed, also. From the USN change journal procmon.chm Stream_Change FileRef 44401 11 ParentRef 44361 32 procmon.chm Named_Data_Extend,Close,Stream_Change FileRef 44401 11 ParentRef 44361 32 procmon.chm Named_Data_Extend,Stream_Change FileRef 44401 11 ParentRef 44361 32 So now, if an ADS is suspected, a good place to look for indications of when the ADS was added to a file or folder would be to parse the USN change journal and look for stream_change entries. This can be valuable during an examination because an ADS does not have any unique time stamps associated with it within the MFT record. An ADS is a DATA attribute within the MFT record, and as such, does not have a unique STANDARD_INFORMATION or FILE_NAME attribute associated with it. Test 3 - File system tunneling In this test, I created a batch file named tunnel.bat in the C Tools folder, with the following contents del procmon.exe echo This is a test file procmon.exe For this test, I ran the batch file, which deletes procmon.exe and then creates a new file named procmon.exe in the same folder, in relatively short order. In fact, for file system tunneling to take effect, the entire process has to happen within 15 seconds by default the time can be changed, or file system tunneling itself disabled, via the Registry . As we'll see, the entire process took place within a second. The original MFT record appears as follows 44631 FILE Seq 4 Links 1 FILE , BASE RECORD . tools Procmon.exe M Fri Nov 8 15 17 17 2013 Z A Fri May 31 20 54 54 2013 Z C Fri Nov 8 15 17 17 2013 Z B Fri May 31 20 54 54 2013 Z FN Procmon.exe Parent Ref 44361 32 Namespace 3 M Fri Nov 8 15 17 17 2013 Z A Fri Nov 8 15 17 17 2013 Z C Fri Nov 8 15 17 17 2013 Z B Fri Nov 8 15 17 17 2013 Z ADS Zone.Identifier After the test was run, the MFT record appeared as follows 44631 FILE Seq 5 Links 1 FILE , DELETED , BASE RECORD M Fri Nov 8 15 17 17 2013 Z A Fri May 31 20 54 54 2013 Z C Fri Nov 8 15 17 17 2013 Z B Fri May 31 20 54 54 2013 Z FN Procmon.exe Parent Ref 44361 32 Namespace 3 M Fri Nov 8 15 17 17 2013 Z A Fri Nov 8 15 17 17 2013 Z C Fri Nov 8 15 17 17 2013 Z B Fri Nov 8 15 17 17 2013 Z ADS Zone.Identifier Here's the new file record for the file 22977 FILE Seq 12 Links 1 FILE , BASE RECORD . tools procmon.exe M Thu Jul 17 20 40 35 2014 Z A Thu Jul 17 20 40 35 2014 Z C Thu Jul 17 20 40 35 2014 Z B Fri May 31 20 54 54 2013 Z FN procmon.exe Parent Ref 44361 32 Namespace 3 M Thu Jul 17 20 40 35 2014 Z A Thu Jul 17 20 40 35 2014 Z C Thu Jul 17 20 40 35 2014 Z B Fri May 31 20 54 54 2013 Z RESIDENT Notice that the only difference between the two 44631 records is the sequence number, and that the original file record is now marked DELETED . What this illustrates is that the MFT record itself is NOT reused during file system tunneling on NTFS, and that a new record is created during the operation. This was something I'd wondered about for some time, and now I can see the effect of file system tunneling. We can see in this case that the MAC times for the new file are all for the date of the testing, and that the B creation date is from the original file record. Also, notice the FILE_NAME attribute time stamps of the new file...very interesting. Also, because the file went from being a PE file to a string, the resulting file is now resident I didn't include the hex dump of the file contents, extracted from the MFT record. This blog post from 2005 explains why tunneling exists at all. From the USN change journal procmon.exe Data_Extend,Close,File_Create FileRef 22977 12 ParentRef 44361 32 procmon.exe Data_Extend,File_Create FileRef 22977 12 ParentRef 44361 32 procmon.exe File_Create FileRef 22977 12 ParentRef 44361 32 Procmon.exe File_Delete,Close FileRef 44631 4 ParentRef 44361 32 When I first read about file system tunneling, I was curious as to whether the original MFT record for the deleted file was simply reused, and this test clearly illustrates that is not the case. Additional Resources - Here's a jIIr post from Corey Harrell in which he discusses the use of the USN change journal and file system tunneling - Eric Huber's blog post on file system tunneling - Blazer Catzen discussed some file system tunneling testing he'd done on David Cowen's Forensic Lunch podcast, and posted the presentation he'd put together on the subject. Test 4 - Copy a file to another location in the same volume In this test, I copied C Windows Logs IE9_NR_setup.log to C Users IE9_NR_setup.log, using drag-n-drop via the Windows Explorer shell. From before MFT 96296 FILE Seq 3 Links 2 FILE , BASE RECORD . Windows Logs IE9_NR_Setup.log M Fri Nov 8 13 26 02 2013 Z A Fri Nov 8 13 26 02 2013 Z C Fri Nov 8 13 26 02 2013 Z B Fri Nov 8 13 26 02 2013 Z FN IE9_NR 1.LOG Parent Ref 1966 1 Namespace 2 M Fri Nov 8 13 26 02 2013 Z A Fri Nov 8 13 26 02 2013 Z C Fri Nov 8 13 26 02 2013 Z B Fri Nov 8 13 26 02 2013 Z FN IE9_NR_Setup.log Parent Ref 1966 1 Namespace 1 M Fri Nov 8 13 26 02 2013 Z A Fri Nov 8 13 26 02 2013 Z C Fri Nov 8 13 26 02 2013 Z B Fri Nov 8 13 26 02 2013 Z From the after MFT, the original file 96296 FILE Seq 3 Links 2 FILE , BASE RECORD . Windows Logs IE9_NR_Setup.log M Fri Nov 8 13 26 02 2013 Z A Fri Nov 8 13 26 02 2013 Z C Fri Nov 8 13 26 02 2013 Z B Fri Nov 8 13 26 02 2013 Z FN IE9_NR 1.LOG Parent Ref 1966 1 Namespace 2 M Fri Nov 8 13 26 02 2013 Z A Fri Nov 8 13 26 02 2013 Z C Fri Nov 8 13 26 02 2013 Z B Fri Nov 8 13 26 02 2013 Z FN IE9_NR_Setup.log Parent Ref 1966 1 Namespace 1 M Fri Nov 8 13 26 02 2013 Z A Fri Nov 8 13 26 02 2013 Z C Fri Nov 8 13 26 02 2013 Z B Fri Nov 8 13 26 02 2013 Z ...and the resulting file 22987 FILE Seq 12 Links 2 FILE , BASE RECORD . Users IE9_NR_Setup.log M Fri Nov 8 13 26 02 2013 Z A Thu Jul 17 20 41 39 2014 Z C Thu Jul 17 20 41 39 2014 Z B Thu Jul 17 20 41 39 2014 Z FN IE9_NR 1.LOG Parent Ref 486 1 Namespace 2 M Thu Jul 17 20 41 39 2014 Z A Thu Jul 17 20 41 39 2014 Z C Thu Jul 17 20 41 39 2014 Z B Thu Jul 17 20 41 39 2014 Z FN IE9_NR_Setup.log Parent Ref 486 1 Namespace 1 M Thu Jul 17 20 41 39 2014 Z A Thu Jul 17 20 41 39 2014 Z C Thu Jul 17 20 41 39 2014 Z B Thu Jul 17 20 41 39 2014 Z Now, one question you might have is that if I dragged-and-dropped the file, shouldn't the record show indications of the file having been accessed Well, we have to remember that as of Vista, the NtfsDisableLastAccessUpdate value is enabled by default, meaning that normal user actions won't cause the From the USN change journal IE9_NR_Setup.log Data_Extend,Data_Overwrite,File_Create FileRef 22987 12 ParentRef 486 1 IE9_NR_Setup.log File_Create FileRef 22987 12 ParentRef 486 1 IE9_NR_Setup.log Data_Extend,File_Create FileRef 22987 12 ParentRef 486 1 CONSENT.EXE-531BD9EA.pf Data_Extend,Data_Truncation,Close FileRef 1582 11 ParentRef 59062 1 CONSENT.EXE-531BD9EA.pf Data_Truncation FileRef 1582 11 ParentRef 59062 1 CONSENT.EXE-531BD9EA.pf Data_Extend,Data_Truncation FileRef 1582 11 ParentRef 59062 1 IE9_NR_Setup.log Data_Extend,Data_Overwrite,Close,File_Create FileRef 22987 12 ParentRef 486 1 From the USN change journal, we see a reference to consent.exe being run this is the dialog that pops up when you drag-and-drop a file between folders, asking if you want to copy or move the file, or cancel the operation. Test 5 - Move a file to another location in the same volume Moved C Windows Logs IE10_NR_setup.log to C Temp IE10_NR_setup.log drag-n-drop, via the Windows Explorer shell The before record 16420 FILE Seq 15 Links 2 FILE , BASE RECORD . Windows Logs IE10_NR_Setup.log M Fri Nov 8 14 24 59 2013 Z A Fri Nov 8 14 24 59 2013 Z C Fri Nov 8 14 24 59 2013 Z B Fri Nov 8 14 24 59 2013 Z FN IE10_N 1.LOG Parent Ref 1966 1 Namespace 2 M Fri Nov 8 14 24 59 2013 Z A Fri Nov 8 14 24 59 2013 Z C Fri Nov 8 14 24 59 2013 Z B Fri Nov 8 14 24 59 2013 Z FN IE10_NR_Setup.log Parent Ref 1966 1 Namespace 1 M Fri Nov 8 14 24 59 2013 Z A Fri Nov 8 14 24 59 2013 Z C Fri Nov 8 14 24 59 2013 Z B Fri Nov 8 14 24 59 2013 Z ...and the after record 16420 FILE Seq 15 Links 2 FILE , BASE RECORD . temp IE10_NR_Setup.log M Fri Nov 8 14 24 59 2013 Z A Fri Nov 8 14 24 59 2013 Z C Thu Jul 17 20 41 58 2014 Z B Fri Nov 8 14 24 59 2013 Z FN IE10_N 1.LOG Parent Ref 44311 7 Namespace 2 M Fri Nov 8 14 24 59 2013 Z A Fri Nov 8 14 24 59 2013 Z C Fri Nov 8 14 24 59 2013 Z B Fri Nov 8 14 24 59 2013 Z FN IE10_NR_Setup.log Parent Ref 44311 7 Namespace 1 M Fri Nov 8 14 24 59 2013 Z A Fri Nov 8 14 24 59 2013 Z C Fri Nov 8 14 24 59 2013 Z B Fri Nov 8 14 24 59 2013 Z Okay, the file was moved copy delete operations , but we might expect to see some changes in the time stamps...shouldn't we Well, in this case, we cannot tell if the FILE_NAME attribute time stamps had been changed, because for this file, all of the time stamps, in all of the available attributes, were the same. We do, however, see that the C entry modified time in the STANDARD_INFORMATION attribute changed as expected and that the parent file reference number changed. From the USN change journal IE10_NR_Setup.log Security_Change FileRef 16420 15 ParentRef 44311 7 IE10_NR_Setup.log Rename_New_Name,Close FileRef 16420 15 ParentRef 44311 7 IE10_NR_Setup.log Rename_New_Name FileRef 16420 15 ParentRef 44311 7 IE10_NR_Setup.log Security_Change,Close FileRef 16420 15 ParentRef 44311 7 IE10_NR_Setup.log Rename_Old_Name FileRef 16420 15 ParentRef 1966 1 CONSENT.EXE-531BD9EA.pf Data_Extend,Data_Truncation,Close FileRef 1582 11 ParentRef 59062 1 CONSENT.EXE-531BD9EA.pf Data_Truncation FileRef 1582 11 ParentRef 59062 1 CONSENT.EXE-531BD9EA.pf Data_Extend,Data_Truncation FileRef 1582 11 ParentRef 59062 1 Again, we see a reference to consent.exe having been launched. I'm not entirely sure why the Security_change reason code in the USN change journal was generated for a move operation. Both tests 4 and 5 validate what's described in MS KB article 299648, keeping in mind that the article only discusses time stamps from the STANDARD_INFORMATION attribute. Summary Again, I ran these tests as a means for determining what different file operations look like in the MFT and USN change journal, and what the effects are on individual records. This information can be helpful in a variety of investigation types, such as malware detection, and finding indications of historical activity and data i.e., files that are no longer on the system . Future Efforts For the future, I'll need to look at copy and move file operations performed at the command line, using the copy and move commands, respectively.






Les derniers articles du site "Windows Incident Response" :

- Training Philosophy
- Cool Stuff, re WMI Persistence
- Windows Registry Forensics, 2E
- Event Logs
- Links Plugin Updates and Other Things
- Tools, Links, From the Trenches, part deux
- From the Trenches
- Updated samparse.pl plugin
- The Need for Instrumentation
- Analysis

---

S'abonner au fil RSS global de la revue de presse

---