As I mentioned in my previous post on this topic, there were two other tests that I wanted to conduct with respect to file system operations and the effects an analyst might expect to observe within the MFT, and the USN change journal. My thoughts were that if an intruder were accessing a system via RDP, they might not do the drag-and-drop method to move files, or if they were accessing the system via a RAT and they only had command line access, they might use native, command line tools to conduct file operations.
Testing Protocol
All of the same conditions exist from the previous tests, in fact, I didn't even boot the VM between tests. What I wanted to do this time is look at what effects one could expect to see for copy and move operations conducted via the command line, rather than via the shell. I wanted to run these tests, as they would better represent the file system operations that may occur during a malware infection.
For this set of tests, I logged into the VM, opened a command prompt and typed the following commands:
C:\>copy c:\tools\eula_30.txt c:\temp\eula_31.txt
C:\>move c:\tools\procmon.exe c:\temp\procmon.exe
Test 1 - copy operation, via the command line
Original file record:
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
Resulting file record:
23643 FILE Seq: 6 Links: 1
[FILE],[BASE RECORD]
.\temp\eula_31.txt
M: Fri Nov 8 15:17:17 2013 Z
A: Thu Jul 24 14:57:41 2014 Z
C: Thu Jul 24 14:57:41 2014 Z
B: Thu Jul 24 14:57:41 2014 Z
FN: eula_31.txt Parent Ref: 44311/7
Namespace: 3
M: Thu Jul 24 14:57:41 2014 Z
A: Thu Jul 24 14:57:41 2014 Z
C: Thu Jul 24 14:57:41 2014 Z
B: Thu Jul 24 14:57:41 2014 Z
From the USN change journal (as with the previous test, these entries are not in order):
eula_31.txt: Named_Data_Extend,Data_Extend,Data_Overwrite,Stream_Change FileRef: 23643/6 ParentRef: 44311/7
eula_31.txt: Data_Extend,Data_Overwrite FileRef: 23643/6 ParentRef: 44311/7
eula_31.txt: Close,File_Create FileRef: 23643/6 ParentRef: 44311/7
eula_31.txt: Data_Extend,Data_Overwrite,Stream_Change FileRef: 23643/6 ParentRef: 44311/7
eula_31.txt: Data_Extend FileRef: 23643/6 ParentRef: 44311/7
eula_31.txt: Named_Data_Extend,Data_Extend,Data_Overwrite,Named_Data_Overwrite,Close,Stream_Change FileRef: 23643/6 ParentRef: 44311/7
eula_31.txt: Named_Data_Extend,Data_Extend,Data_Overwrite,Named_Data_Overwrite,Stream_Change FileRef: 23643/6 ParentRef: 44311/7
eula_31.txt: File_Create FileRef: 23643/6 ParentRef: 44311/7
Results:
The results of the file copy operation, with respect to the MFT record (i.e., attribute time stamps, parent ref number, etc.) are identical to what we saw when the test was performed via the shell. The most notable exception is the absence of references to consent.exe being launched in the USN change journal data.
Test 2 - move operation, via the command line
File record following previous test:
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
File record following move operation:
22977 FILE Seq: 12 Links: 1
[FILE],[BASE RECORD]
.\temp\procmon.exe
M: Thu Jul 17 20:40:35 2014 Z
A: Thu Jul 17 20:40:35 2014 Z
C: Thu Jul 24 14:57:55 2014 Z
B: Fri May 31 20:54:54 2013 Z
FN: procmon.exe Parent Ref: 44311/7
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
From the USN change journal:
procmon.exe: Rename_New_Name,Close FileRef: 22977/12 ParentRef: 44311/7
procmon.exe: Rename_New_Name FileRef: 22977/12 ParentRef: 44311/7
procmon.exe: Rename_Old_Name FileRef: 22977/12 ParentRef: 44361/32
Results
The results of this test were similar to the results observed in the previous test, with the exception that consent.exe was not run. The only change to the record was the modification of the parent ref number, which was reflected in the MFT entry change (C) time stamp in the $STANDARD_INFORMATION attribute being updated.
Take Aways
A couple of interesting "take aways" from this testing...
1. When a file is copied or moved via the shell, we can expect to see consent.exe run, and on workstation systems (Win7, Win8.1) an application prefetch/*.pf file created. This artifact on Win8.1 will be very beneficial, as the structure of *.pf files on that platform allows for up to 8 launch times to be recorded, adding much more granularity to our timelines.
2. If an intruder accesses a system using compromised credentials, such as via RDP, there can be a great deal of activity 'recorded' in various locations within the system (i.e., Registry, Windows Event Log, etc.). However, it an intruder is accessing the system via a RAT, there will be an apparent dearth of artifacts on the system, unless the analyst knows where to look. This, of course, is in lieu of any additional instrumentation used to monitor the endpoints.
3. For those who perform dynamic analysis of malware and exploit kits for the purposes of developing threat intel, adding this sort of thing to your analysis would very likely assist in developing a much more detailed picture of what's happening on the host, even weeks or months after the fact.
Final Note
I know that this testing is pretty rudimentary, and that much of the results have been documented already (via MS Knowledge Base articles, the SANS 2012 DFIR poster, etc.), but I wanted to take the testing a step further by looking at other artifacts in the individual MFT records, as well as the USN change journal. In a lot of ways, the results of these tests serve a IoCs that can be used to help analysts add additional context to their timelines, and ultimately to their analysis.
Awesome follow-up on your previous article. Very helpful indeed. Thank you for sharing.
ReplyDelete