Security Best Practices Logging in a Windows Environment

Security Best Practices – Logging in a Windows Environment

Logging is essential to maintaining security in an IT environment. The monitoring of logs can help prevent security incidents and when a security event occurs, logs are essential for the proper and timely resolution of the event. Unfortunately, little thought is usually given to log collection; it is usually just an item to be checked off for compliance. To be used effectively, logs need to be collected into a central location and some provision made for the analysis of the logs. The size of the organization and the number of logs collected will be the major factor in determining the log collection and storage methodology. When choosing the correct logs to collect, the environment and purpose of the log collection needs to be considered.

Log Collection

Centralization of logs is critical for two reasons. One, logs need to be centralized for effective monitoring and analysis. If logs are scattered among all computers and servers, they will seldom if ever be analyzed. Two, when a security incident does occur, it is essential that the logs be copied to a central location to preserve them. Many times the malicious actors delete logs to cover their tracks. If the logs have been sent to a central log collector; there is a greater chance of them being preserved for analysis.

The size of the IT environment and the number of logs collected both factor into the method used to centralize the logs. Here are some general guidelines.

1)If the IT environment has less than 10 to 15 Windows Servers and all of the servers and workstations are Windows 7/Windows 2008R2 or greater, Windows Event Log forwarding and collecting can be used. In this environment, one server would be designated as the collector and logs would be forwarded to it from the other servers and key workstations. In this environment, the regular Windows Event Viewer can be used to examine the logs and set up alerts using Task Manager. PowerShell can also be used to generate alerts using the Get-EventLog and Send-MailMessage cmdlets. One minor advantage to this solution is that no agent needs to be installed on the server/workstation. The major disadvantage to this method is the limited analytic capabilities of the Windows Event Viewer.

To set up Windows Event log Forwarding and Collecting see or

2)If the IT environment has less than 75 servers, then one of the Open Source SIEM solutions will work well. The most basic solution would be to use a log shipper like the free, Eventlog Forwarder for Windows, by SolarWinds, and a basic Linux Syslog Server. This would adequately collect the logs but would not provide any real analytic capabilities. For analysis, solutions such as Greylog the ELK stack (elasticsearch, logstash, kibana) should be used.

3)If the IT environment has greater than 75 servers, then one of the commercial SIEM solutions should be used, such as LogRhythm, QRadar, ArcSight, or Splunk. These provide the collection, consolidation and analysis capabilities needed for a large environment.

No matter what the size of the environment, the key factor in log collection and monitoring is having a person who is trained in the analysis of logs and has been assigned the duty of watching the logs and verifying that the logs are being collected. Log collection with no analysis is useless.

What logs to Collect

The collection and monitoring of logs in an IT environment is useful for much more than security. And more than Windows logs need to be collected for security purposes. We are concerned here, however, only with the collection of logs from Windows servers and workstations in a security context.

Not all the logs that can be collected are of equal value. The following ranking will be used.

1)Critical. These logs must be collected.

2)Good. It is good to collect these logs and will greatly enhance your Security environment.

3)Best. Collecting these logs is best practice. They may increase the logging requirements because of the volume of logs collected and should be evaluated with this in mind.

What should logs be collected from?

Workstations: At the least, logs should be collected from all admin workstations. If there are workstations that are used for things like corporate banking transactions or credit card transactions, those should be monitored also. Every environment will have critical workstations from which logs should be collected.

Servers: Logs should be collected from all servers. Critical servers, such as Domain Controllers, DNS and DHCP servers and any server in a DMZ environment should have additional logs collected.

Critical Logs

The absolute essential log to collect is the Security Log. Almost as important is the System Log. By default, these logs are limited to 20MB in size and are configured to over write old entries with new ones when this size is reached. These two logs should be collected for all workstations deemed critical and all servers. The settings for these logs can be controlled through Group Policy on either the local or domain level. These GPO settings can be found at

Computer Configuration/Policies/Administrative Templates/Windows Components/Event Log Service.

You might want to increase the size of the log file on computers that are in a remote location and might have connectivity issues.

Good Logs

Along with the Security and System Logs, it is good to have Application and Setup Logs. By default the Setup Log is not enabled. The configuration of the Application and Setup Logs is controlled by Group Policy Objects at

Computer Configuration/Policies/Administrative Templates/Windows Components/Event Log Service

as listed above. Other logs to collect, found at %SystemRoot%\System32\Winevt\Logs\ are

• Microsoft-Windows-PowerShell%4Operational.evtx,
• Microsoft-Windows-SMBServer%4Security.evtx,
• Microsoft-Windows-TaskScheduler%4Operational.evtx,
• Microsoft-Windows-TerminalServices-RemoteConnectionManager%4Operational.evtx.

Domain Controllers: Domain Controllers have a special role in a Windows Network and require special logging. In the GPO

Computer Configuration/Policies/Windows Settings/Security Settings/Local Policies/Audit Policy

the following settings should be configured.

An additional level of logging on domain controllers can be enabled by turning on debug logging for the net logon service. This will show you whenever a computer or user attempts to authenticate to the DC. This log is found at%windir%\debug\netlogon.log. See for instructions about how to enable net logon debug logging.

DNS Servers: DNS logs should be collected and sent to the log collection system. This can, among other things,be used to track which computers have malware by their DNS queries. DNS logging is turned off by default and has to be enabled. In the DNS console, right click on the server name and choose Properties.

Then on the Debug Logging tab select the options for the log and enter a place for the log to be saved.

DHCP Servers: DHCP logs can help give the history of which computers had which IP in the past. Often it is weeks or months before the presence of a malicious user is detected. Historical context can help track lateral movement throughout an environment. DHCP logging is turned on by default. If it is not the options is found in the Properties page.

The path where the audit logs are kept is configured in the Advanced Page.

The logs are kept by day and are rolled over automatically. Only a week’s worth of logs are kept. It is essential that these logs be sent to a centralized log collection system.

Servers in a DMZ: Enhanced logging on servers in a DMZ should be considered. What this logging will entail will be specific to the purpose of the server, e.g. a web server should send the web server logs to the collection point. Care should be taken in how the logs are transmitted back into the internal environment as this will open up a possible avenue for malware infiltration.

Best Logs

Note: Many of the log settings below rely on Advanced Audit PoliciesGPO. These policies will only work with Windows 7/Windows Server 2008R2 and higher.

Registry Keys and Files:Access to critical Windows Registry Keys can be logged. A common way to assure persistence for malware is to install themselves in the Run Keys. Access to these Registry Keys can be monitored, it is a twostep process. First, set the GPO

Computer Configuration/Policies/Windows Settings/Security Settings/Advanced Audit Policies Configuration/Audit Policies/Object Access – Audit Registry – Success and Failure.

Second, configure the GPO

Computer Configuration/Policies/Windows Settings/Security Settings/Registry

to monitor “Machine\SOFTWARE\Microsoft\Windows\CurrentVersion\Run”. Other keys to monitor would be the RunOnce Key and the Run Keys under the Wow6432Node. On administrative and critical workstations you should monitor the users Run keys.

Special files, directories, and file shares can be monitored in the same way. In place of the GPO Computer Configuration/Policies/Windows Settings/Security Settings/Advanced Audit Policies Configuration/Audit Policies/Object Access – Audit Registry, you can Audit File Systemor Audit File Share. Once again it is a two-step process. After setting Audit File System or Audit File Share, the paths to audit must be added under

Computer Configuration/Policies/Windows Settings/Security Settings/File System.

Logon/Logoff Events: Enhanced security logging can be enabled by turning on the logging of Logon and Logoff events. This is enabled in the GPOs

Computer configuration/Policies/Windows Settings/Security Settings/Advanced Audit Policies Configuration/Audit Policies/Logon – Success and Failure and

Computer configuration/Policies/Windows Settings/Security Settings/Advanced Audit Policies Configuration/Audit Policies/Logoff – Success. There is no reason to audit Logoff failures.

Account and Group Activity:Turn on logging for account and group activity. Malicious users frequently create new accounts just for their use and then adding them to an administrative Security Group. You can monitor this activity by configuring the following GPO:

Computer configuration/Policies/Windows Settings/Security Settings/Advanced Audit Policies Configuration/Audit Policies/Account Management. Turn on auditing for the following settings:

Audit Computer Account Management, Audit Security Group Management and Audit User Account Management.

Windows Firewall:If Windows Firewall is turned on the connection status can be logged. This is controlled by GPO at

Computer Configuration/Policies/Windows Settings/Security Settings/Advanced Audit Policy Configuration/Audit Policies/Object Access/Audit Filtering Platform Connection. Turn on Success and Failure auditing. On a busy server this can create a lot of log entries.

Process Monitoring:Process monitoring can provide critical information when a Security Event occurs, however, it will create a massive number of log entries. Only enable this on critical servers or when bad behavior is suspected. Process monitoring can be enabled through the GPO at

Computer Configuration/Policies/Windows Settings/Security Settings/Advanced Audit Policy Configuration/Audit Policies/Detailed Tracking – Audit Process Creation and Audit Process Termination.

Beginning with Windows 8.1/Windows Server 2012, Microsoft added the ability to log all command lines associated with process creation. This can be turned on if you have enabled logging of process creation as above by setting the following GPO:

Computer Configuration/Policies/Administrative Templates/System/Audit/Process Creation – Include command line in process creation events. This ability was backported to Windows 2008 with KB3004375.

PowerShell:PowerShell Script Block Monitoring can be enabled through a GPO for Windows 2012 and Windows 8.1. This logs all command line arguments used for all PowerShell commands, similar to the previous command line logging for processes. The GPO to turn on PowerShell command line logging is Computer Configuration/Policies/Administrative Templates/Windows Components/Windows PowerShell – Turn On PowerShell Script Block Logging.

Audit Policy: Now that logging is turned up, turn on logging for changes to the audit policies by configuring the following GPO:

Computer configuration/Policies/Windows Settings/Security Settings/Advanced Audit Policies Configuration/Audit Policies/Policy Change.

Sysmon:An additional logging resource that will allow you to turn up logging even more on critical servers or workstations is the Sysmon utility from Windows Sysinternals. This allows greatly increased monitoring. From the Sysinternals website, Sysmon includes the following capabilities.

• Logs process creation with full command line for both current and parent processes.
• Records the hash of process image files using SHA1 (the default), MD5, SHA256 or IMPHASH.
• Multiple hashes can be used at the same time.
• Includes a process GUID in process create events to allow for correlation of events even when Windows reuses process IDs.
• Include a session GUID in each events to allow correlation of events on same logon session.
• Logs loading of drivers or DLLs with their signatures and hashes.
• Optionally logs network connections, including each connection’s source process, IP addresses, port numbers, hostnames and port names.
• Detects changes in file creation time to understand when a file was really created. Modification of file create timestamps is a technique commonly used by malware to cover its tracks.
• Automatically reload configuration if changed in the registry.
• Rule filtering to include or exclude certain events dynamically.
• Generates events from early in the boot process to capture activity made by even sophisticated kernel-mode malware.

Microsoft Windows includes many resources to enhance logging. By no means have all logging possibilities been presented here. Not all of the logging suggestions presented above will be equally valuable in all situations. The most important element in any logging scheme is the person or persons that are responsible for monitoring the logs.

Tom Willett

10/15/2015