Windows Security Log

The Security Log, in Microsoft Windows, is a log that contains records of login/logout activity or other security-related events specified by the system's audit policy. Auditing allows administrators to configure Windows to record operating system activity in the Security Log. The Security Log is one of three logs viewable under Event Viewer. Local Security Authority Subsystem Service writes events to the log. The Security Log is one of the primary tools used by Administrators to detect and investigate attempted and successful unauthorized activity and to troubleshoot problems; Microsoft describes it as "Your Best and Last Defense".[1] The log and the audit policies that govern it are also favorite targets of hackers and rogue system administrators seeking to cover their tracks before and after committing unauthorized activity.[2]

Types of data logged

If the audit policy is set to record logins, a successful login results in the user's user name and computer name being logged as well as the user name they are logging into.[3] Depending on the version of Windows and the method of login, the IP address may or may not be recorded. Windows 2000 Web Server, for instance, does not log IP addresses for successful logins, but Windows Server 2003 includes this capability.[4] The categories of events that can be logged are:[5]

The sheer number of loggable events means that security log analysis can be a time-consuming task.[6] Third-party utilities have been developed to help identify suspicious trends. It is also possible to filter the log using customized criteria.

Attacks and countermeasures

Administrators are allowed to view and clear the log (there is no way to separate the rights to view and clear the log).[7] In addition, an Administrator can use Winzapper to delete specific events from the log. For this reason, once the Administrator account has been compromised, the event history as contained in the Security Log is unreliable.[8] A defense against this is to set up a remote log server with all services shut off, allowing only console access.[9]

As the log approaches its maximum size, it can either overwrite old events or stop logging new events. This makes it susceptible to attacks in which an intruder can flood the log by generating a large number of new events. A partial defense against this is to increase the maximum log size so that a greater number of events will be required to flood the log. It is possible to set the log to not overwrite old events, but as Chris Benton notes, "the only problem is that NT has a really bad habit of crashing when its logs become full".[10]

Randy Franklin Smith's Ultimate Windows Security points out that given the ability of administrators to manipulate the Security Log to cover unauthorized activity, separation of duty between operations and security-monitoring IT staff, combined with frequent backups of the log to a server accessible only to the latter, can improve security.[11]

Another way to defeat the Security Log would be for a user to log in as Administrator and change the auditing policies to stop logging the unauthorized activity he intends to carry out. The policy change itself could be logged, depending on the "audit policy change" setting, but this event could be deleted from the log using Winzapper; and from that point onward, the activity would not generate a trail in the Security Log.[5]

Microsoft notes, "It is possible to detect attempts to elude a security monitoring solution with such techniques, but it is challenging to do so because many of the same events that can occur during an attempt to cover the tracks of intrusive activity are events that occur regularly on any typical business network".[12]

As Benton points out, one way of preventing successful attacks is security through obscurity. Keeping the IT department's security systems and practices confidential helps prevent users from formulating ways to cover their tracks. If users are aware that the log is copied over to the remote log server at :00 of every hour, for instance, they may take measures to defeat that system by attacking at :10 and then deleting the relevant log events before the top of the next hour.[10]

Log manipulation is not needed for all attacks. Simply being aware of how the Security Log works can be enough to take precautions against detection. For instance, a user wanting to log into a fellow employee's account on a corporate network might wait until after hours to gain unobserved physical access to the computer in their cubicle; surreptitiously use a hardware keylogger to obtain their password; and later log into that user's account through Terminal Services from a Wi-Fi hotspot whose IP address cannot be traced back to the intruder.

After the log is cleared through Event Viewer, one log entry is immediately created in the freshly cleared log noting the time it was cleared and the admin who cleared it. This information can be a starting point in the investigation of the suspicious activity.

In addition to the Windows Security Log, administrators can check the Internet Connection Firewall security log for clues.

Writing false events to the log

It is theoretically possible to write false events to the log. Microsoft notes, "To be able to write to the Security log, SeAuditPrivilege is required. By default, only Local System and Network Service accounts have such privilege".[13] Microsoft Windows Internals states, "Processes that call audit system services . . . must have the SeAuditPrivilege privilege to successfully generate an audit record".[14] The Winzapper FAQ notes that it is "possible to add your own 'made up' event records to the log" but this feature was not added because it was considered "too nasty," a reference to the fact that someone with Administrator access could use such functionality to shift the blame for unauthorized activity to an innocent party.[8] Server 2003 added some API calls so that applications could register with the security event logs and write security audit entries. Specifically, the AuthzInstallSecurityEventSource function installs the specified source as a security event source.[15]

Admissibility in court

The EventTracker newsletter states that "The possibility of tampering is not enough to cause the logs to be inadmissible, there must be specific evidence of tampering in order for the logs to be considered inadmissible".[16]

gollark: You missed PXE.
gollark: My list of desirable codes is far, far longer.
gollark: Er, no.
gollark: BRB HMU IMO PXE DM CB BSA MP3
gollark: HMU?

See also

References
  1. The NT Security Log - Your Best and Last Defense, Randy Franklin Smith
  2. Protecting the NT Security Log, Randy Franklin Smith, Windows IT Pro, July 2000.
  3. Tracking Logon and Logoff Activity in Windows 2000, Microsoft.
  4. Capturing IP Addresses for Web Server Logon Events, Randy Franklin Smith, Windows IT Pro, October 2003.
  5. Auditing Policy, Microsoft.
  6. “Five Mistakes of Security Log Analysis”, Anton Chuvakin, Ph.D., GCIA, GCIH.
  7. Access Denied: Letting Users View Security Logs, Randy Franklin Smith, July 2004 -- intermittently broken link as of 2007-9-27.
  8. Winzapper FAQ, NTSecurity.
  9. Know Your Enemy: II, Honeynet Project.
  10. Auditing Windows NT, Chris Benton.
  11. Ultimate Windows Security, Randy Franklin Smith.
  12. Security Monitoring and Attack Detection, Microsoft, Aug. 29, 2006.
  13. Auditing Security Events, Microsoft.
  14. Microsoft Windows Internals, Microsoft.
  15. AuthzInstallSecurityEventSource Function, Microsoft.
  16. EventTracker Newsletter, April 2006, Will your log files stand up in court? Authentication vs. logon events?
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.