Windows xp event log forensics

For information, please join the Google Group forensicswiki-reborn. 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. 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. 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.

Many hacking attempts exploit buffer overflows or similar attacks that can cause an application to fault. Similar to the events in the application log, Event ID 26 in the system log may indicate a successful buffer overflow attempt.

Event ID indicates a memory dump was performed and will list the location of the dump file. Showing a particular patch was installed at a particular time can be useful in refuting claims of infection or exploit by malware.

Event ID 19 shows successful installation of an automated patch. Event ID shows specific package hotfix installations. The initial Windows installation with build number should be one of the first listed events assuming log recycling has not occurred with an event ID Log-on failures.

Network log-on failures, such as those generated by FTP, show up in the system log. Event ID indicates a failure to authenticate against a known account, and a series of these events may indicate password guessing or a brute force tool use.

Alteration of machine information. Event ID denotes a system name change. Investigations into a particular machine name that does not match with existing information should look for this ID to indicate a potential change of name after an event occurred. If the machine in question is acting as a print server, the jobs printed and their source will be listed as Event ID The originating machine for the request is not shown, but the user name of the requestor is.

The security log is the mother of all logs in forensic terms. Log-ons, log-offs, attempted connections, and policy changes are all reflected in the event contained therein.

Unfortunately, security logging is turned off by default. It needs to be enabled by Group or Local Policy to be useful. To support later investigations, the Audit Policy under the Local or Group Policy should be enabled for the following actions at a minimum:. These major categories will cover 95 percent of the security events analyzed in an investigation. The impact of further auditing needs to be weighed against system performance and disk storage issues.

Although it would be useful, from a forensic standpoint, to audit all file access, the practical implications of doing so make it infeasible.

The overhead associated with file access auditing does not mean that no file access should be audited. The company's key intellectual property shares if they can be isolated should have auditing enabled and regularly reviewed at a file-level. Most important to an investigation are log-on and log-off events.

These are essential to proving who performed an action on a computer at a particular time. Both failed and successful log-ons are relevant, and other security events support specific investigations. The main event types of use to an investigation are detailed in the next sections. Successful log-on events are used to show who performed a particular action. Interactive log-on events are characterized by Event ID , with a subcategory defining the log-on type.

Table lists the key log-on types frequently encountered. Logging in locally when a domain controller is unavailable and used the cached user credentials. Most of the log-ons encountered of interest will be of type 2 indicating a local log-on. Showing an individual used remote access to connect can be done with Type ten log-ons. Connections across a network for example, via FTP will appear as type three log-ons, though connecting to or viewing a network share is a different Event ID Predicting when a user came back from lunch or reengaged his or her notebook in the morning can be had with logons of type 7.

Log-offs are also of interest. They bound the time an individual was connected. Log-offs are slightly less reliable for time as there can be events that force a log-off that is not recorded such as power outages. Depending on the amount of data logged, the failure event time may be able to be calculated based on the lack of log entries for a specific period.

Remote Desktop Connection events can be bounded by connection types other than log-offs as well. Disconnects leave the user logged in but detach the actual terminal machine from the server. Reconnects re-attach and are accompanied by log-on events.

The disconnection is an Event ID of and the subsequent reconnection a Prior versions of Windows recorded only the local workstation name. Failures to log on are one of the best indicators of password guessing or bruteforce attacks on a system. Failed attempts are logged based on the reason for failure: wrong password or user name Event ID ; may be a hacking attempt , account is disabled or expired or locked Event IDs and and , respectively; could be password sharing or disgruntled former employees , or the user tries to log in to a resource to which he or she is not permitted access Event ID ; possible unauthorized access.

Unfortunately, failed log-ons also occur in large numbers for legitimate reasons. Users forget passwords, automated tools are misconfigured, and Caps Lock keys are accidentally depressed, making it difficult to separate out malicious log-on failures. In generally, malicious failures will be more numerous in nature, will be closer together if an automated tool is used , and may show failures to multiple account names from the same source machine.

Changing of the audit policy specifically removing the auditing of certain events is indicative of a hacking attempt or root kit installation. Event ID is a change of audit policy. Any change from prior Event ID entries that show a removal minus sign of policy that was previously present plus sign should be questioned. Auditing for specific NTFS files and folders can be turned on using the Advanced button on the Security tab within the particular object's properties.

Enabling auditing on an object can log anything from attempted reads of that object to successful deletion of that object. If this level of auditing is enabled, it can show when a given entity was accessed and by whom and when a file or folder was changed or deleted, or highlight unauthorized access attempts on key objects. Event Log Explorer benefits for IT-administrators. Advantages for managers and decision makers Order Event Log Explorer license.

This great productivity is the result of the powerful features of Event Log Explorer: Event log consolidation You can analyze events from several sources event logs, files at one time. Event Log Explorer lets you consolidate different event logs into one single view. This feature is crucial for timeline analysis. Extremely powerful filters Event Log Explorer provides 5 five ways to filter events by virtually any criteria, from a simple quick filters filter by a selected template to complex filters that refine linked events e.

Custom columns Event Log Explorer makes it possible to display event description details e. Therefore, this feature eliminates the need for keeping track of all event descriptions and makes Event Log Explorer a great time saver.