Day 4 FOR508.4
Day 4 Timeline Analysis
http://journeyintoir.blogspot.com/2014/01/it-is-all-about-program-execution.html
http://www.kazamiya.net/en/NTFS_Timestamps
https://fwhibbit.es/en/what-happened-the-abc-of-the-macb
https://www.fireeye.com/blog/threat-research/2012/09/incident-response-ntfs-indx-buffers-part-2-internal.html
Both of the below posters are very, very important during the exam. Be sure to take them with you.
MAC timestamps
https://www.andreafortuna.org/2017/10/06/macb-times-in-windows-forensic-analysis/
| MACB | MACE |
| (M) odification | (M) odified |
stored at $MFT
$SI ($STANDARD_INFOERMATION)= What you look at with Explorer, cmd, PS1
$FN ($FILE_NAME) = Only modifyable by the kernel
Compare $SI and $FN to find time manipulations (i.e. analyzeMFT.py)
| Operation | Modified ($SI) | Accessed ($SI) | Birth ($SI) (Create) | |
| File Create | YES | YES | YES | |
| File Modify | YES | NO | NO | (A) not changed due to NtfsDisableLastAccessUpdate = 1 by default Vista+ |
| File Copy (explorer) | NO (inherited from original) | YES | YES | |
| File Copy (cmd) | NO (inherited from original) | YES | YES | |
| File Access | NO | NO | NO | (A) not changed due to NtfsDisableLastAccessUpdate = 1 by default Vista+ |
$STANDARD_INFO
$STANDARD_INFO ($SI) stores file metadata such as flags, the file SID, the file owner and a set of MAC(b) timestamps.
$STANDARD_INFO is the timestamp collected by Windows explorer, fls, mactime, timestomp, find and the other utilities related to the display of timestamps.
$FILE_NAME
The $File_Name attribute contains forensically interesting bits, such as MACB times, file name, file length and more.
Timestamps are only updated with the attribute is changed.
Files can have either one or two $File_Name attributes depending on how long the file name is:
- Short file names (“file.txt”) has only one $File_Name attribute.
- Long file names (“extremelylongfilename.txt”) will have two $File_Name attributes.
- One for the long file name, and one for the DOS-compatible short name (EXTRE~1.TXT).
Carrier's File System Forensic Analysis book says, "Windows does not typically update this set of temporal values like it does with those in the "$STANDARD_INFORMATION" attribute, and they frequently correspond to when the file was created, moved, or renamed," (page 318).
Deleting a file:
- The filename is removed from the parent directory index $I30
- The MFT entry is unallocated by cleaning the in use flag $Bitmap
- The Clusters are unallocated
- Change the file system journal $LogFile
→ $FILE_NAME remains intact
What are the differences of:- $STANDARD_INFO can be modified by user level processes like timestomp.
- $FILE_NAME can only be modified by the system kernel. (There are no known anti-forensics utilities that can accomplish this.)
Finding the approx. time when the intrution/abuse began to limit the number of data and sources to look at
How to detect Anti-Forensics Timestamp Anomalies?
Tool such as timestomp allow attackers to backdate a file to an arbitrary time in order to trying to hide it in system32 or other similar directories.
So, during analysis you can use analyzeMFT.py in order to check if the $FILE_NAME time occurs after the $STANDARD_INFORMATION Creation Time. If this anomaly occurs, it is likely that an attacker has been alterated timestamps in $STANDARD_INFO using timestomp.
Timestamp Analysis for Lateral MovementWhen a file is copied via SMB (net use):
- the modification time is inherited from the original
- the creation time will be the time of the lateral movement → PIVOT POINT
"log2timeline.py with filters"
https://www.andreafortuna.org/2018/02/16/forensic-timeline-creation-my-own-workflow/ Required toolshttps://www.sleuthkit.org/sleuthkit/
http://www.volatilityfoundation.org/
https://github.com/log2timeline/plaso
| Step | Action | Description |
| 1 | fls -r -m / Evidence1.E01 > Evidence1-bodyfile | Extract filesystem bodyfile from the .E01 file (physical disk dump): |
| 2 | | identification of the type of memory image is a mandatory step. |
| 3 | vol.py -f Evidence1-memoryraw.001 --profile=Win7SP1x86 timeliner --output=body > Evidence1-timeliner.body | Run the timeliner plugin against volatile memory dump using volatility |
| 4 | vol.py -f Evidence1-memoryraw.001 --profile=Win7SP1x86 mftparser --output=body > Evidence1-mftparser.body | Run the mftparser volatility plugin, in order to spot some strange MFT activities. |
| 5 | cat Evidence1-timeliner.body >> Evidence1-bodyfile cat Evidence1-mftparser.body >> Evidence1-bodyfile | Combine the timeliner and mftparser output files with the filesystem bodyfile |
| 6 | mactime -d -b Evidence1-bodyfile 2012-04-02..2012-04-07 > Evidence1-mactime-timeline.csv | Extract the combined filesystem and memory timeline |
| 7 | grep -v -i -f Evidence1-mactime-timeline.csv > Evidence1-mactime-timeline-final.csv | Optionally, filter data using grep and applying the whitelist |
"log2timeline.py without filters"
| Step | Action | Description |
| 1 | log2timeline.py plaso.dump Evidence1.E01 | Gather timeline data and create the plaso.dump |
| 2 | psort.py -z "UCT" -o L2tcsv plaso.dump "date > '2012-04-03 00:00:00' AND date < '2012-04-07 00:00:00'" -w plaso.csv | Filter the timeline using psort.py |
| 3 | grep -v -i -f whitelist.txt plaso.csv > supertimeline.csv | Optionally filter data using grep and applying the whitelist |
Using AutoTimeline (AndreaFortuna)
git clone https://github.com/andreafortuna/autotimeliner.git
./autotimeline.py -f ./*.raw -t 2018-10-17..2018-10-21