Sign in Subscribe

Windows Baseline Logging

Mike

• 5 min read

When people ask what their baseline configuration should be, in terms of logging, I feel like it often gets answered with general advice regarding knowing your environment, having different configurations for file servers vs domain controllers, etc. This is true advice, but not particularly helpful. You might not know your environment. Maybe you're in the first IT or security role the company has ever had. Everyone needs to start somewhere, this is my attempt at putting together something that can be deployed to any server and/or workstation and -then- tweaked as needed.

Because this is so broad, it's not going to be perfect. I've tried to turn on things that would be important for intrusion monitoring or investigation without flooding event logs. If I've missed something important, please comment or send me a message. I can't promise to include it, but it would be good for people to know. I may do a future article with what events and logs you should centrally collect.

Ideally these things -should- be centrally collected via Windows Event Forwarding, Splunk, or whatever technology works for you. This is both to ensure logs are retained for a long enough period of time (don't roll off) and ensure that they can't be modified or erased (accidentally or otherwise).

Update Jan 2023:
I got tired of setting these manually and scripted the entire thing here: https://github.com/BeanBagKing/BaselineLogging

Update May 2022:
Prefetch
One thing I'm finding that would be super useful is to have prefetch enabled within a server environment. Unlike everything else here, this is one thing that I have not implemented in a live environment and thus don't know if there will be any performance impact. Instructions for Server 2012 do appear to still work fine on Server 2019. How to enable PreFetch in Windows Server | (wordpress.com)

Lastly, set timestamps for all systems to UTC. This makes it easier to avoid mix-ups caused by daylight savings times, crossing time zones to a different datacenter, or differences in one set of log files that writes to UTC (and adjusts to the systems time zone) vs another that actually writes the logs in the time zone.
/Update

Sysmon

Local Policy Logging Settings

  • Computer Configuration\Policies\Windows Settings\Security Settings\Advanced Audit Configuration\Detailed Tracking
    • Audit PNP Activity
      • Success
    • Audit Process Creation
      • Success and Failure

detailed-tracking

  • Administrative Templates\System\Audit Process Creation
    • Include command line in process creation events
      • Enabled

audit-process-creation

  • Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
    • Audit: Force audit policy subcategory settings
      • Enabled

security-options

  • Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy Configuration\Account Management
    • Audit Other Account Management Events
      • Success and Failure
    • Audit Security Group Management
      • Success and Failure
    • Audit User Account Management
      • Success and Failure

account-management

  • Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy Configuration\Logon/Logoff
    • Audit Account Lockout
      • Success and Failure
    • Audit Logoff
      • Success
    • Audit Logon
      • Success and Failure
    • Audit Other Logon/Logoff Events
      • Success and Failure
    • Audit Special Logon
      • Success and Failure

logon-logoff

  • Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy Configuration\Object Access
    • Audit Other Object Access Events
      • Success and Failure

object-access

PowerShell Logging

Windows versions below 10 and Server 2016 must first be upgraded to PowerShell 5. Sample details for this can be found here: https://www.rootusers.com/install-powershell-5-windows-server-2008-r2/
While sometimes necessary for compatibility, removing PowerShell v2 is ideal so attackers can't downgrade. This can be done via Windows Features -> uncheck Windows PowerShell 2.0
Check your installed versions with:
Get-ItemProperty HKLM:\SOFTWARE\Microsoft\PowerShell\*\PowerShellEngine | select PowerShellVersion
Monitor for systems with the PowerShell 2.0 DLL in:
C:\Windows\Microsoft.Net\Framework\v2.0.50727\System.dll

A note on the PSTranscription logs. These will not purge automatically based on any volume or time. They may fill up your drive. If you use the below, they are also in a writeable location. You can solve this by changing this location to a write only file share, or picking them up via something like Splunk and makeing a scheduled task to periodically purge the directory (Get-ChildItem C:\PSTranscription -Recurse | Where-Object { $_.LastWriteTime -lt (Get-Date).AddHours(-1) } | Remove-Item –Recurse might help you get started, use something like AddDays(-90) if you can't centralize)

  • Computer Configuration\Administrative Templates\Windows Components\Windows PowerShell
    • Turn on Module Logging
      • Enabled
      • Click Show next to Module Names and enter * in the value field to record all modules
    • Turn on PowerShell Script Block Logging
      • Enabled
    • Turn on PowerShell Transcription
      • Enabled
      • Enter "C:\PSTranscription" for the output directory
      • Check Include Invocation Headers

windows-powershell

  • Add "profile.ps1" file containing the following lines to C:\Windows\System32\WindowsPowerShell\v1.0

Another warning here. If you don't have the proper executionpolicy set, you'll get the "File X cannot be loaded. The file X is not digitally signed." warning every time a user launches PowerShell. There's multiple ways to fix this, such as purchasing a code signing cert, signing with an internal CA, self signing (here's some instructions I use in my lab), or setting execution policy to Unrestricted. Remember that while execution policy isn't a security boundry, it is a "saftey net" so just setting unrestricted probably isn't the best option.

$LogCommandHealthEvent = $true
$LogCommandLifecycleEvent = $true

profileps1

Firewall Logging

Each profile gets its own log (domain_pfirewall.log, private_pfirewall.log, public_pfirewall.log), and logs both dropped and successful connections. Make sure you change the name for each profile so that, when being reviewed, you can tell which profile was active.

Note: If this is configured via Group Policy, it should be configured in "Computer Configuration\Policies\Windows Security\Security Settings\Windows Firewall with Advanced Security settings" NOT the pre-Win 2003 location of "Network Templates\Network Connections".

Sign up for more like this.

Enter your email
Subscribe