- Windows 11 taskbar: remove chat icon, customize search field with Group Policy - Tue, Oct 3 2023
- Allow non-admins to access Remote Desktop - Thu, Sep 28 2023
- Which WSUS products to select for Windows 11? - Tue, Sep 26 2023
You may wonder why you should encrypt Windows log files. This feature was triggered by the introduction of Scriptblock Logging in PowerShell 5, which stores all entered commands in the event log. These commands may also include credentials, which should not be visible to unauthorized persons.
Activation via group policies
Basically, Protected Event Logging is a system-wide feature that can be used by all applications and Windows services. If you activate it under Windows 10, PowerShell is currently the only user of this encryption.
To enable secure event logging, Microsoft provides a setting in Group Policy. It is called Enable Protected Event Logging and can be found under Computer Configuration > Policies > Administrative Templates > Windows Components > Event Logging.
The encryption of PowerShell entries in the event log can be enabled via group policies
To successfully activate this setting, a certificate specifically issued for document encryption [[hier der Link zum Text über das Ausstellen von Zertifikaten für die Dokumentverschlüsselung]] is required. Its public key is used to encode the log entries. The GPO editor accepts several ways to link the policy to the certificate.
You can store it on a file share and specify its path. If the certificate is available in the store of the local computer, the user's fingerprint will also suffice. A simple method is to export the certificate in Base64 encoded form, the contents of which can simply be copied into the text field.
Decrypting logs with PowerShell
Once the GPO is in effect, you can no longer read the event log history of the PowerShell commands entered on those machines. However, the Event Viewer lacks the necessary functions to decode the logs using the private key.
The Event Viewer only presents the encrypted entries; it cannot decode them
Therefore, you must make these log entries readable with PowerShell. The Unprotect-CmsMessage cmdlet, the opposite of Protect-CmsMessage, decrypts them.
For example, if you want to decipher the latest entry in the PowerShell log, you could retrieve it via Get-WinEvent and pipe it to Unprotect-CmsMessage:
$msg = Get-WinEvent Microsoft-Windows-PowerShell/Operational ` -ComputerName myPC -MaxEvents 2 -Credential domain\user "Last log entry as clear text:" $msg[1] | select -ExpandProperty Message | Unprotect-CmsMessage # $msg[0] is always "prompt"
Decrypting PowerShell logs with Unprotect CmsMessage
A complete script for this purpose can be found on Emin Atac's blog.
The problem with script block logging is that longer command sequences are split across multiple log entries. Therefore, in this case you would have to aggregate the individual sections and then pass them to Unprotect-CmsMessage.
Encrypting files
Protect-CmsMessage can also be used to encrypt any file. If their contents are binary, then you should convert to a Base64 representation first.
Usage scenarios here may also include protecting sensitive data in scripts or password files against unauthorized access. However, this technology is certainly not intended as an alternative to an encrypting file system or even a Bitlocker.
Because PowerShell uses the cryptographic message syntax standard, you can decrypt encoded files using other tools on different platforms, such as OpenSSL on Linux. Therefore, this PowerShell feature is also suitable for exchanging confidential data between different operating systems.
The process is relatively simple. Protect-CmsMessage expects the input file via the Path parameter. Alternatively, you can provide the contents to be encrypted via the Content parameter or via a pipeline. The target file is specified via OutFile; otherwise, the output is stdout.
Simple application of Protect CmsMessage and Unprotect CmsMessage
Other required information includes the certificate you want to use. The To parameter, which accepts the fingerprint, subject name, or path to a certificate, serves this purpose.
Conversely, Unprotect-CmsMessage only needs the content for decryption (via Content or Path); passing it via a pipe is also possible. The To parameter can be omitted if the certificate is in the local store.
Problems with the character set
Watch out for the character encoding of files. Otherwise, you will be surprised by a distorted result after decryption. This is the case, for example, with the following procedure:
Get-Process > process.txt Protect-CmsMessage -Path process.txt -out process.enc -To 61F4C2FFF9CC… Unprotect-CmsMessage -Path process.enc
Incorrect character encoding destroys content during encryption and decryption
To avoid such unwanted effects, save the output using:
Get-Process | Out-File -FilePath process.txt -Encoding utf8
If you prefer the first variant with redirection to a file, then you must convert the content to the correct character set when it is read for encryption:
Get-Content -Raw -Encoding UTF8 process.txt | Protect-CmsMessage -To "CN=Max Mustermann" -out .\process.enc
Correct decoding of encrypted data when using UTF 8
With this variant, you can take advantage of the appropriate features of Get-Content.
First of all, thanks for the novelty. great job How encryption affects scenarios in which logs are sent to 3rd as splunk or SIEM. Thank you !!
True, as kinomakino says, how would it affect scenarios with SIEM? Will it cease to be compatible or will there be a module?
You will have to check with your vendor. Since Microsoft uses the open standard Cryptographic Message Syntax it should not be too difficult for these tools to dycrypt the logs. Maybe there are hooks in the SIEM software for running your own PowerShell scripts to performing this task.