Windows 10 Protected Event Logging
Protected Event Logging is a new feature in Windows 10 and uses a cryptographic standard designed for event logs to prevent sensitive data getting into the hands of hackers. In this Ask the Admin, I’ll look at how this feature is implemented in Windows.
Collecting information about exactly what is happening across your systems is usually a good thing, even if it can be hard to process so much data. PowerShell script-block logging, when enabled, writes code to the Windows Event Log that ran even if a hacker attempts to evade detection by using encoding. But with all this information stored in the logs, there is a risk that sensitive information, like credentials, could be exposed if the logs are compromised.
For more information on how hackers try to avoid detection, see What Is Antimalware Scan Interface (AMSI) in Windows 10? on the Petri IT Knowledgebase.
To protect sensitive data that might find its way into the event log, Windows 10 Protected Event Logging (PEL) encrypts data using the IETF Cryptographic Message Syntax (CMS) standard as it is written to the logs. The logs can be decrypted once they have been moved to a centralized log server using Windows Event Forwarding. PEL is not enabled by default and PowerShell is the only participating application in Windows 10.
The CMS encryption standard used by PEL is public key cryptography. A public key is deployed to all machines where Windows PEL is enabled. The corresponding private key is used to decrypt the logs on the collector server or other Security Information and Event Management (SIEM) solution.
Windows PEL can be turned on using the Enable Protected Event Logging setting in Group Policy under Windows Components -> Administrative Templates -> Event Logging. You will need to provide a certificate when enabling this feature. The certificate must have the Document Encryption enhanced key usage (126.96.36.199.4.1.311.80.1) and either the Data Encipherment or Key Encipherment key usages. Microsoft says that the certificate can be identified in the Group Policy setting in one of the following ways:
- The content of a base-64 encoded X.509 certificate (for example, as offered by the ‘Export’ option in Certificate Manager)
- The thumbprint of a certificate that can be found in the Local Machine certificate store (usually deployed by PKI infrastructure)
- The full path to a certificate (can be local, or a remote share)
- The path to a directory containing a certificate or certificates (can be local, or a remote share)
- The subject name of a certificate that can be found in the Local Machine certificate store (usually deployed by PKI infrastructure)
It is important that the certificate set in Group Policy does not include the private key. If for whatever reason the certificate you specify in Group Policy cannot be used, an event is written to the event log and logging continues but unencrypted.
Windows Management Framework v5
Windows PEL is included in PowerShell v5, which is part of the Windows Management Framework (WMF) v5. Windows 10 and Windows Server 2016 are the only operating systems that contain the Group Policy setting to enable Windows PEL. Any version of Windows that has been upgraded to WMF v5 can make use of PEL if it is enabled manually using the following PowerShell cmdlets, where ProtectedEventLogging.cer is the path to the certificate containing the public key you want to deploy.
$cert = Get-Content C:\temp\ProtectedEventLogging.cer –Raw Enable-ProtectedEventLogging –Certificate $cert
The Unprotect-CmsMessage PowerShell cmdlet can process logs encrypted using CMS. Or use standard PowerShell cmdlets, like Get-WinEvent, to retrieve encrypted logs provided that a certificate containing the private key is installed on the device where the cmdlet is run.
When PowerShell script-block logging is enabled on a device, consider whether the resulting logs should be encrypted. On servers that are already highly secured, such as domain controllers, this might not be worth the administrative overhead. Once a domain controller is hacked, it is already likely ‘game over’. Much will also depend on the scripts that you run in your organization. If they contain credentials, or information about devices that might help a hacker gain access, then you should take steps to protect this data.