Improving your logging practices and utilizing the Windows audit settings described in this article can increase visibility and detection capabilities in your environment. Logs gathered through these audit policies can also offer more evidence during forensic investigations during and post-compromise.
Note: Implement these changes via a group policy object pushed to all appropriate hosts to ensure consistent logging across your environment.
Why the Need for Verbose Logging?
With phishing, supply chain, and mal-spam campaigns on the rise, vectors used by adversaries are becoming more and more sophisticated and difficult to identify. New attacks are using LOLBins (Living Off the Land Binaries) and making detection harder every day.
While default logging on devices may have been appropriate historically, newer attacks are increasingly using an operating system’s own tools to avoid the need to deploy executables, reducing attacker footprints and visibility considerably. Malicious actions are much easier to hide in thousands of PowerShell logs than in a handful of program-installed logs. These developments result in attacks requiring identification with a much smaller footprint, and this can often fall outside of a user’s purview with out-of-the-box logging. Logs previously considered too noisy, such as Windows process logs, are now required to detect these smaller footprint attacks.
Recommended Logs to Enable
The following recommended audit policies will provide added visibility into your devices. Note that enabling additional logs can create an increased burden on some systems. However, consider setting up ‘canary’ windows hosts if the resource impact is a blocker after testing.
Process Monitoring
Process monitoring provides a greater level of visibility into applications running on your Windows machine. By themselves, these applications may be mundane; however, based on how, why, and by whom applications are started could raise concerns. For example, Microsoft Outlook launching isn’t of concern, but it may be troublesome if the application starts command prompt.
A new process has been created - Event ID 4688
- Use: Logs a process being created
- Purpose: Identify processes that attempt to run on a machine
- Audits on success
- More information: https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4688
A process has exited - Event ID 4689
- Use: Logs when a process stops
- Purpose: Identify processes that have run on a machine
- Audits on success
- More information: https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4689
Windows object access attempted - Event ID 4663
- Use: Logs whenever an object is accessed in Windows
- Purpose: Identify when files, registries, kernels, and more are touched or modified and what process modified them
- Audits on success
- More information: https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4663
PowerShell Monitoring
PowerShell monitoring allows for greater detection of Living Off the Land techniques and provides visibility into specific commands that are run. PowerShell monitoring can assist in detecting specialized tools—such as Mimikatz—that may be downloaded to increase an attacker’s foothold.
PowerShell Executing Pipeline - Event ID 4100
- Exclusive to PS5
- Use: Logs when PowerShell encounters an error while trying to execute
- Purpose: Identify PowerShell scripts that fail to run but can still be malicious; identify before they succeed
- More information: https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_group_policy_settings?view=powershell-7.1#console-session-configuration
PowerShell Module Logging - Event ID 4103
- Event code 800 in PS4
- Use: Logs portions of a script’s run, de-obfuscated code, and output variables
- Purpose: Provide additional visibility into the purpose of PowerShell script run, letting us potentially see output of PowerShell scripts
- More information: https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_group_policy_settings?view=powershell-7.1#turn-on-module-logging
PowerShell Script Block Auditing - Event ID 4104
- Exclusive to PS5
- Use: Logs PowerShell script block contents, such as the script’s code
- Purpose: Provide visibility into the contents of executed PowerShell scripts
- Turn on PowerShell Script Block Logging in the group policy
- More information: https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows?view=powershell-7.1#enabling-script-block-logging
Installations
Monitoring attempted and successful installations can identify spyware, greyware, and unauthorized software being utilized. Attackers attempting to secure a stronger foothold with persistence may install applications, leaving backdoors that re-install their malware.
Service Install Attempted - Event ID 601
- Use: Logs a service attempting to install; precursor to below, 4697
- Purpose: Droppers and other malware can fail to deploy when getting caught by AV or compatibility issues; this can indicate that a backdoor or other compromise exists
- More information: https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=601
Service Installed - Event ID 4697
- Use: Logs whenever a service is installed
- Purpose: In an enterprise environment, all software installed should be approved and expected
- More information: https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4697
Comments
0 comments
Please sign in to leave a comment.