Difference between pages "Windows Event Log (EVT)" and "New Technology File System (NTFS)"

From ForensicsWiki
(Difference between pages)
Jump to: navigation, search
(Tools)
 
(External links)
 
Line 1: Line 1:
MS Windows 2000, XP and 2003 typically maintain three Event Log files: Application, System, and Security.  They are generally found in the C:\Windows\system32\config directory. Server versions of the OS may maintain additional Event Logs (DNS Server.evt, Directory Service.evt, File Replication Service.evt) depending upon the functionality of the server.
+
The '''New Technology File System''' ('''NTFS''') is a [[file system]] developed and introduced by [[Microsoft]] in 1995 with [[Windows]] NT. As a replacement for the [[FAT]] file system, it quickly became the standard for [[Windows 2000]], [[Windows XP]] and [[Windows Server 2003]].
  
It should be noted that Vista, Windows 2008, and Windows 7 use a different Windows Event Log format.
+
The features of NTFS include:
  
Each log file consists of a Header record and the Body. The body again consists of Event records, the Cursor record and unused space. The body could form a ring buffer, where the cursor record will mark the border between the oldest and the newest event record. Unused space could be empty, slack and padding.
+
* [[Hard-links]]
 +
* Improved performance, reliability and disk space utilization
 +
* Security [[access control lists]]
 +
* File system journaling
  
== Header Record ==
+
== Time Stamps ==
The Header Record defined as [http://msdn.microsoft.com/en-us/library/bb309024%28VS.85%29.aspx ELF_LOGFILE_HEADER] on MSDN consists of:
+
# uint32 length of record in bytes, fixed 0x30
+
# char magic[4], fixed 'LfLe' (for Event log file)
+
# uint32 unknown, fixed 0x0100 0x0000, possibly indicates version
+
# uint32 unknown, fixed 0x0100 0x0000, possibly indicates version
+
# uint32 offset of first event record
+
# uint32 offset of next event record
+
# uint32 number of next event record
+
# uint32 number of first event record
+
# uint32 filesize (see below)
+
# uint32 flags (see below)
+
# uint32 retention period in seconds
+
# uint32 length of record in bytes (again), fixed 0x30
+
  
Offsets and record numbers are updated only during a file close operation, that is if the DIRTY flag (see below) is unset. Consult the cursor record in that case.
+
NTFS keeps track of lots of time stamps. Each file has a time stamp for 'Create', 'Modify', 'Access', and 'Entry Modified'. The latter refers to the time when the MFT entry itself was modified. These four values are commonly abbreviated as the 'MACE' values. Note that other attributes in each MFT record may also contain timestamps that are of forensic value.
  
Filesize is updated only during some recovery operations.
+
Additional information on how NTFS timestamps work when files are moved or copied is available here: [http://support.microsoft.com/kb/299648 Microsoft KB 299648]
  
=== Flags ===
+
=== Changes in Windows Vista  ===
* 0x0001 DIRTY if set, flag is set after first first write after an open operation.
+
* 0x0002 WRAPPED is set, flag is set if the log wrapped around.
+
* 0x0004 FULL if set, flag is set if an event record could not be written because of size limitations and the retention policy in effect.
+
* 0x0008 PRIMARY if set, BACKUP if unset. This flag possibly depends on the origin of a log file, usage seems change between earlier (pre SP1) and later versions (SP4) of Windows 2000.
+
  
== Cursor Record ==
+
In Windows Vista, NTFS no longer tracks the Last Access time of a file by default. This feature can be enabled by the user if desired via setting the registry key 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisableLastAccessUpdate' to '0'.
  
# uint32 length of record in bytes, fixed 0x28
+
== Alternate Data Streams ==
# uint32 magic[4], fixed 0x11111111 0x22222222 0x33333333 0x44444444
+
The '''NTFS''' file system includes a feature referred to as Alternate Data Streams (ADSs).  This feature has also been referred to as "multiple data streams", "alternative data streams", etc.  ADSs were included in '''NTFS''' in order to support the resource forks employed by the Hierarchal File System ([[HFS]]) employed by Macintosh systems. 
# uint32 offset of first event record
+
# uint32 offset of next event record
+
# uint32 number of next event record
+
# uint32 number of first event record
+
# uint32 length of record in bytes, fixed 0x28
+
  
== Event Record ==
+
As of [[Windows XP]] SP2, files downloaded via Internet Explorer, Outlook, and Windows Messenger were automatically given specific "zoneid" ADSs.  The [[Windows]] Explorer shell would then display a warning when the user attempted to execute these files (by double-clicking them).
  
Details of the Event record can be found in Microsoft's MSDN library under [http://msdn.microsoft.com/library/default.asp?url=/library/en-us/eventlog/base/eventlogrecord_str.asp EVENTLOGRECORD].
+
Sysadmins should be aware that prior to Vista, there are no tools native to the [[Windows]] platform that would allow you to view the existence of arbitrary ADSs.  While ADSs can be created and their contents executed or viewed, it wasn't until the "/r" switch was introduced with the "dir" command on Vista that arbitrary ADSs would be visible.  Prior to this, tools such as [http://www.heysoft.de/Frames/f_sw_la_en.htm LADS] could be used to view the existence of these files.
  
== Padding ==
+
Microsoft FSRM (File System Resource Manager) also uses ADS as part of 'file classification'.
  
If
+
Examiners should be aware that most forensic analysis applications, including [[EnCase]] and ProDiscover, will display ADSs found in acquired images in red.
* a log file has reached its configured size limit
+
* and the retention policy allows wrapping
+
* and the remaining size is larger than 0x38 but smaller than the event record to be written,  
+
then
+
* the event log service writes the first part of the event record (to record offset 0x38)
+
* fills the remaining space with a padding of 0x0027
+
* continues to write the second part of the event record (starting at record offset 0x38) at the top of the body (immediately after the header, that is at file offset 0x30).
+
  
== Message Templates ==
+
== Advanced Format (4KB Sector) Hard Drives ==
 +
NTFS does not natively handle drives that use the new standard of 4KB sectors. For information on this, see [[Advanced Format]].
  
When written to disk, EVT log records contain very little human-readable context.  Log entries are made human-readable at analysis time through tools such as the event viewer, by combining pre-defined log templates (stored in system DLLs and EXEs) with variable data stored in the EVT file.  The templates and variable data are combined with a call to FormatMessage(), which means the templates look similar to printf()'s format strings.
+
== Transactional NTFS (TxF) ==
  
When event viewer (or other log viewing tools) displays log records, it has to determine which DLLs store the message templates.  This linking information is stored in the registry, and is specific to each type of log (System, Security, Application, etc).  These entries ultimately point out a list of DLLs which contain the message templates.  Each log record contains a relative virtual address (RVA) to reference the associated message template.  The lower 16 bits of this RVA is typically displayed as the Message ID, but this alone generally isn't enough to uniquely reference a message template.
+
According to MSDN Transactional NTFS (TxF) allows file operations on an NTFS file system volume to be performed in a transaction.  
  
All of this means that EVT files aren't really complete on their own.  The files which store the core meaning of the log entry are separate from the logs themselves and this creates several analysis problems.  First of all, an attacker could modify DLLs or the registry in order to change the meaning of logs without having to touch the EVT file at all. Secondly, when software is uninstalled in the future, it could cause some EVT records to lose their context.  Finally, EVT files aren't particularly portable to other systems, since some log records could rely on message templates which don't exist on other systems.  One must be careful to keep these issues in mind when analyzing EVT logs.
+
Several TxF related file-system-metadata files can be found in the file-system-metadata directory: \$Extend\$RmMetadata\. TxF also uses the MFT attribute $LOGGING_UTILITY_STREAM with the name $TXF_DATA.
  
== See Also ==
+
TxF uses the [[Common Log File System (CLFS)]]
* [[Windows XML Event Log (EVTX)]]
+
* [[Windows]]
+
  
== External Links ==
+
== External links ==
=== File Format ===
+
* [http://en.wikipedia.org/wiki/NTFS Wikipedia: NTFS]
* [http://code.google.com/p/libevt/downloads/detail?name=Windows%20Event%20Log%20%28EVT%29.pdf Windows Event Log (EVT) format], by the [[libevt|libevt project]]
+
* [http://msdn.microsoft.com/en-us/library/bb968806%28v=VS.85%29.aspx MSDN on Transactional NTFS]
 +
* [http://en.wikipedia.org/wiki/Transactional_NTFS Wikipedia on Transactional NTFS]
 +
* [http://www.tzworks.net/prototype_page.php?proto_id=12  Windows NTFS Metadata Extractor Utility] Free tool that can be run on Windows, Linux or Mac OS-X
 +
* [http://www.tzworks.net/prototype_page.php?proto_id=28 Graphic Engine for NTFS Analysis (gena)] (GUI to view NTFS internals/extract data on live systems)
 +
* [http://sourceforge.net/projects/linux-ntfs/files/NTFS%20Documentation/ Linux-ntfs Documentation] Detailed documentation of the NTFS format by the Linux-NTFS driver creators.
 +
* [http://support.microsoft.com/kb/140365 Default cluster size for NTFS, FAT, and exFAT]
 +
* [http://code.google.com/p/libfslibs/downloads/detail?name=New%20Technologies%20File%20System%20%28NTFS%29.pdf New Technologies File System (NTFS)], by the [[libfslibs|libfslibs project]], August 2009
  
=== Event identifiers ===
+
[[Category:File Systems]]
* [http://eventid.net/ EventID.net]
+
 
+
=== Windows 2000 ===
+
* [http://www.eventreporter.com/common/en/securityreference/win-eventcorrelation-processtracking.php Correlation of Windows Process Tracking Events]
+
 
+
== Tools ==
+
 
+
* [http://projects.sentinelchicken.org/grokevt GrokEVT] is a set of forensics scripts designed to make sense of EVT logs for investigations.  Along with RegLookup, it is able to combine registry information and event log templates to place EVT data in context.  (UN*X platforms only.)
+
* [http://www.cpan.org/modules/by-authors/id/H/HC/HCARVEY/ File::ReadEVT] is a Perl module that parses event log files for the purpose of forensics.
+
* [http://www.tzworks.net/prototype_page.php?proto_id=4 Windows Eventlog Viewer] Free tool that can be run on Windows, Linux or Mac OS-X. Parses Windows XP, Vista and Windows 7 eventlogs.
+
* [http://www.tzworks.net/prototype_page.php?proto_id=25 evtwalk] Command line tool to pull reports (password changes, logons, clock changes, system start/stop, and credential changes) from Windows event logs.
+
* [[libevt]]
+
* [https://github.com/williballenthin/LfLe lfle.py], by [[Willi Ballenthin]]
+
 
+
[[Category:File Formats]]
+

Revision as of 20:28, 9 July 2013

The New Technology File System (NTFS) is a file system developed and introduced by Microsoft in 1995 with Windows NT. As a replacement for the FAT file system, it quickly became the standard for Windows 2000, Windows XP and Windows Server 2003.

The features of NTFS include:

Time Stamps

NTFS keeps track of lots of time stamps. Each file has a time stamp for 'Create', 'Modify', 'Access', and 'Entry Modified'. The latter refers to the time when the MFT entry itself was modified. These four values are commonly abbreviated as the 'MACE' values. Note that other attributes in each MFT record may also contain timestamps that are of forensic value.

Additional information on how NTFS timestamps work when files are moved or copied is available here: Microsoft KB 299648

Changes in Windows Vista

In Windows Vista, NTFS no longer tracks the Last Access time of a file by default. This feature can be enabled by the user if desired via setting the registry key 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisableLastAccessUpdate' to '0'.

Alternate Data Streams

The NTFS file system includes a feature referred to as Alternate Data Streams (ADSs). This feature has also been referred to as "multiple data streams", "alternative data streams", etc. ADSs were included in NTFS in order to support the resource forks employed by the Hierarchal File System (HFS) employed by Macintosh systems.

As of Windows XP SP2, files downloaded via Internet Explorer, Outlook, and Windows Messenger were automatically given specific "zoneid" ADSs. The Windows Explorer shell would then display a warning when the user attempted to execute these files (by double-clicking them).

Sysadmins should be aware that prior to Vista, there are no tools native to the Windows platform that would allow you to view the existence of arbitrary ADSs. While ADSs can be created and their contents executed or viewed, it wasn't until the "/r" switch was introduced with the "dir" command on Vista that arbitrary ADSs would be visible. Prior to this, tools such as LADS could be used to view the existence of these files.

Microsoft FSRM (File System Resource Manager) also uses ADS as part of 'file classification'.

Examiners should be aware that most forensic analysis applications, including EnCase and ProDiscover, will display ADSs found in acquired images in red.

Advanced Format (4KB Sector) Hard Drives

NTFS does not natively handle drives that use the new standard of 4KB sectors. For information on this, see Advanced Format.

Transactional NTFS (TxF)

According to MSDN Transactional NTFS (TxF) allows file operations on an NTFS file system volume to be performed in a transaction.

Several TxF related file-system-metadata files can be found in the file-system-metadata directory: \$Extend\$RmMetadata\. TxF also uses the MFT attribute $LOGGING_UTILITY_STREAM with the name $TXF_DATA.

TxF uses the Common Log File System (CLFS)

External links