Windows Server 2016 security auditing for enhanced threat detection

First published on TECHNET on Jan 30, 2017

2016 includes new audit events to help with early detection of malicious activity in your datacenter. You can find the complete list of the events from this

reference paper

, and new events in 2016

here

under the Security auditing section.

In this blog post, I would like to highlight a few of these events, which are easy to configure and provide a good starting point to improve detection capabilities in your environment.

Detecting malicious reconnaissance attempts to access SAM

The Security Account Manager (SAM) is a database file, which stores users' passwords. A common attack is to access SAM remotely to enumerate user groups, such as finding all the users in the local admin group on a server. On 2016, when an attacker with insufficient privilege runs a query on the to identify highly privileged accounts, you will see the following events on the server:



Event 16962 and 16969 are generated by default, and 16965 is generated if you set this registry key on the server:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsa

REG_DWORD RestrictRemoteSamEventThrottlingWindow = 0

You can find these events under Windows LogsSystem, with event source Directory-Services-SAM.

Alerting on suspicious activities that should not occur on server machines: Security Audit logs

You can enable granular security audit logs by enabling individual group polices, under Computer ConfigurationWindows SettingsSecurity SettingsAdvanced Audit Policy ConfigurationSystem Audit polices. The

reference paper

has the complete list of the events you can monitor. I went through all of them, and like to recommend the following as they are particularly important on server:

  • Detailed TrackingAudit PNP Activity:
    • Event 6416 can be used to detect when new devices are attached to the server

  • Account ManagementAudit User Account Management:
    • Event 4724 can be used to detect when an account password is reset by another account
    • Event 4798: A user's local group membership was enumerated

  • Account ManagementAudit Security Group Management:
    • Event 4799: A security-enabled local group membership (BUILTINAdministrators) was enumerated

  • Logon and LogoffAudit Account Lockout
    • Event 4625: Account failed to log on when the account was already locked out.

  • Audit system integrity:
    • Event 4816: RPC detected an integrity violation while decrypting an incoming message (We recommend monitoring this event especially on High Value Asset [HVA] computers, because it can be a sign of malicious activity.)
    • Event 5038: Code integrity determined that the image hash of a file is not valid. The file could be corrupt due to unauthorized modification or the invalid hash could indicate a potential disk device error.
    • Event 6281: Code Integrity determined that the page hashes of an image file are not valid. The file could be improperly signed without page hashes or corrupt due to unauthorized modification. The invalid hashes could also indicate a disk device error.
    • Event 6410: Code integrity determined that a file does not meet the security requirements to load into a process.

      Code Integrity

      is a feature that improves the security of the operating system by validating the integrity of a driver or system file each time it is loaded into memory. Code Integrity detects whether an unsigned driver or system file is being loaded into the kernel, or whether a system file has been modified by that is being run by a user account with administrative permissions. For example, when a driver tries to modify memory pages, the system will log this event.

Conclusion

Security monitoring is not easy. The new addition of the security events in Windows Server 2016 builds the foundation for better threats detection. I'm going to share more detection logic as I learn more, and I'd love to hear your feedback or monitoring experiences. You can reach us by email at WinSecFeedback@microsoft.com.

 

This article was originally published by Microsoft's Data Center Security Blog. You can find the original article here.