Default logging in Windows sucks, it doesn’t log much useful data and default storage quotas are ridiculously low. I mean 20Mb for a log? Really?
When responding to incidents I often see that logging wasn’t configured properly in the environment making it harder to spot any malicious activity, as well as limiting forensics evidence. Correct configuration of logging is one of the best things you can do to get a grip on your environment and detect adversary activity.
Setup a centralized logging
It is useful to ship logs to some central location where you can work with them in a single place. This can be your SIEM product, some kind of log management solution or even just another server where you work with logs via Event Viewer or some scripts. It will also help in case attacker alter or delete logs locally.
To do that you have two options – One is to use a built in subscriptions option and second is to install some kind of agent on all computers that will ship logs to your server.
Subscriptions based logging
There is plenty of articles about how to configure subscriptions logging, so I won’t cover that. Basically what you need to do is to configure WinRM service, configure what events to forward, then choose a “pull” or “push” mode. There is some pain to configure forwarding between domain and non-domain computers, unfortunately I didn’t find a good guide for that.
Check those links for a guide on how to configure subscriptions:
https://www.nsa.gov/ia/_files/app/spotting_the_adversary_with_windows_event_log_monitoring.pdf
https://www.loggly.com/ultimate-guide/centralizing-windows-logs/
Agent based logging
For agents you can use some popular open source solutions or use agents provided with your logging product.
You can use agents like nxlog – http://nxlog.org/
or Snare – http://www.snarealliance.com/
Agent setup is useful for small environment, for big enterprise it is better to use subscriptions to aggregate logs on a single server and then you can use agent on that server to forward them where you need to.
I personally use awesome graylog product – https://www.graylog.org/ for log management with nxlog agent in my lab.
Here is sample of my nxlog config:
<Input in>
Module im_msvistalog
ReadFromLast True
# For windows 2003 and earlier use the following:
# Module im_mseventlog
Query <QueryList>\
<Query Id="0">\
<Select Path="Security">*</Select>\
<Select Path="Microsoft-Windows-TaskScheduler/Operational">*</Select>\
<Select Path="System">*</Select>\
<Select Path="Windows PowerShell">*</Select>\
<Select Path="Microsoft-Windows-PowerShell/Operational">*</Select>\
<Select Path="Microsoft-Windows-AppLocker/EXE and DLL">*</Select>\
<Select Path="Microsoft-Windows-AppLocker/MSI and Script">*</Select>\
<Select Path="Microsoft-Windows-Application-Experience/Program-Inventory">*</Select>\
</Query>\
</QueryList>
</Input>
Configure retaining of logs
By default logs will rollover when size limit is reached. You might want to increase a maximum size of logs and save some old logs locally in case you centralized collection system go down.
This is configured via GPO here:
Computer Configuration → Policies → Administrative templates → Windows Components → Event Log service
Set maximum size of each log and enable both “Retain old events” and “Backup log automatically when full” to archive your old logs when maximum size is reached.
Unfortunately I didn’t find a way to limit a number of saved log files similar to linux logrotate neither I found a way to archive other logs located in Application and service logs, so you need to delete old files manually.
Log process creation
Monitoring processes is one of the simplest ways to spot adversary activity as malware and shellcode needs to run. Even in rootkit case there is initial infection vector and payload that need to run before rootkit is installed and able to conceal itself. This also allow you to quickly apply frequency analysis and baseline your environment.
Before enabling this make sure you are ready to handle the volume as this will generate a lot of events.
To enable process logging you need to configure the following GPO settings located under:
Computer Configuration → Policies → Windows settings → Security Settings → Advanced Audit Policy Configuration→ Detailed Tracking
Enabling this will generate 4688 and 4689 event ids respectively. Logging when processes is terminated is useful to determine how long the activity was going, but if you struggling with amount of events being logged you can disable this. You will also get process information populated in some other logged events as a bonus.
In Windows Server 2012 Microsoft introduced audit commadline option that was backported into Windows 2008. This option allow you to grab a commandline arguments that was passed to a process, greatly expanding ability to catch malware and hacking tools. For example this will allow you to see what commands passed via cmd.exe /c instead of just simply logging that cmd.exe process was run.
To use this in 2008 environment make sure you have KB3004375 installed – read more about this here https://support.microsoft.com/en-us/kb/3004375
To enable this you need to configure the following GPO settings located under:
Computer Configuration → Policies → Administrative Templates → System → Audit Process Creation
Here is how a sample event will look:
Another way to get process information is to use the Sysinternals Sysmon tool. It is installed as a service and log detailed proccess information in a separate application log including hashes, network connections, loaded drivers and DLLs with signature verification.
Here is how it looks when a new process created:
Here is network connections log:
Log firewall connections
I know many people disable built in Windows firewall, but using host-based firewall is a good practice and provide a lot of benefits such as ability to control which application and services have network access. Windows firewall is very flexible, allowing you to control things like applications, services, users and computers and with centralized management via GPO it doesn’t take a huge administration burden to use. Best of all it’s free and already deployed so I highly recommend to take advantage off this.
One of the common gaps I see in networks today is ability to monitor internal network connections within subnets and between subnets which is critical to incident response and detecting lateral movement. Often it is because deploying expensive network sensors to every subnet is not practical or not possible, but you don’t have to!
You can enable logging of windows firewall to get a detailed information of connections including applications which you wouldn’t get with network sensor.
To enable it you need to configure the following GPO settings located under:
Computer configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policies Configuration → Audit Policies → Object Access
I don’t recommend to enable “Audit Filtering Platform Packet Drop” logging as it appears to be log the same data as Connection when connection is blocked multiple times.
Here is how permitted connection look:
Here is blocked connection:
It also logs attempts to bind a port:
Log files and registry access
Monitoring access to important files is critical, but we can do better than that.
We can also monitor access to common folders used by attackers such as users Temp or ProgramData and typical persistence locations such as Run and RunOnce registry keys. This approach can be extended to pretty much any number of use cases where folder or registry monitoring is useful. For example, you can pull all registry locations checked by Sysinternals Autoruns utility and add them for monitoring of any changes, this will give you a persistence monitoring for a whole network. Neat, huh?
To configure that, you need to enable the following GPO settings located under:
Computer configuration → Policies → Windows Settings →Security Settings → Advanced Audit Policies Configuration → Audit Policies → Object Access
You need to enable Audit File System and Audit Registry for folders and registry keys respectively.
After that you need to configure Audit on specific registry keys and folders manually or deploy them via GPO.
Here is an example of how to do it via GPO:
Go to
Computer configuration → Policies → Windows Settings →Security Settings → File System
And configure desired folders to monitor
Here, I added ProgramData and TEMP folders:
Then select what actions to monitor:
Usually, monitoring for file creation, deletion and execution is the most useful.
Same can be done for registry.
Go to
Computer configuration → Policies → Windows Settings →Security Settings → Registry
Here I added Run and RunOnce keys:
Here is example event that gets logged for folders:
And here is for registry:
Log network share access
Network shares is a popular way to exchange files in Windows networks. Windows also make use of them for some system functions and every computer on the network have so called administrative shares open which basically mean every hard drive is shared for admin users. Hence, attackers also like to use them for lateral movement, staging and data ex-filtration, so we need to know who is accessing what over the network.
To accomplish this we need to configure the following GPO settings located under:
Computer configuration → Policies → Windows Settings →Security Settings → Advanced Audit Policies Configuration → Audit Policies → Object Access
Here is example when share is created and then deleted:
Here is when access was attempted:
You might want to enable Detailed File Share audit as well, but I don’t recommend it as it doesn’t generate that useful data, but volume will be even higher:
Log scheduled tasks
Scheduled tasks has long been favorite with attackers, leveraged for persistence and lateral movement. By default they already logged in a dedicated log located in Microsoft-Windows-Task Scheduler/Operational and contains most useful information such as task name and action.
So you could simply collect those logs.
Here is example of created task and what was run afterwards:
But if you really want, you can collect full information about tasks.
You need to enabled the following settings in GPO located under:
Computer configuration → Policies → Windows Settings →Security Settings → Advanced Audit Policies Configuration → Audit Policies → Object Access
Here is a full task:
Unfortunately you will get full task in xml format logged inside a message, making it another challenge to work effectively with that information. How useful it will be would depend on your logging product ability to parse this xml further or not. Overall I think default logging is more useful and easier to work with.
Log Logon/Logoff activity
A lot of incidents involve stolen credentials so monitoring where people logging on as well as unsuccessful attempts to login is crucial. Especially for remote access like VPN and RDP.
You need to enabled the following settings in GPO located under:
Computer configuration → Policies → Windows Settings →Security Settings → Advanced Audit Policies Configuration → Audit Policies → Logon/Logoff
If you use NPS server also enable Audit Network Policy Server
Here is typical event:
Log Account management activity
Monitoring for new accounts and changes in existing ones is important as attackers absolutely love to have backdoor accounts, but will only work if you have a proper change management process in place otherwise you will have to consult every change with your admins which quickly become a burden to you and them.
You need to configure the following GPO settings located under:
Computer configuration → Policies → Windows Settings →Security Settings → Advanced Audit Policies Configuration → Audit Policies → Account Management
Here is example event:
And here is example when user is added to local admin group:
Log changes to audit policies
Attackers don’t like to leave any evidence and might just disable auditing, so you need to closely monitor for any potentially unauthorized changes in audit settings.
To do that you need to enable the following GPO settings located under:
Computer configuration → Policies → Windows Settings →Security Settings → Advanced Audit Policies Configuration → Audit Policies → Policy Change
Here is example event:
Log powershell activity
Powershell attacks is on the rise, check my previous article for information about logging powershell activity.
Conclusion
Correct logging configuration is critical to defending a Windows network. You can get a great visibility into your network and have a better chance to spot malicious activity early and have ability to reconstruct attacker activity to some degree during forensics investigations. Unfortunately there is still a lot of networks with default or minimal logging options, so I hope this article will raise awareness and more people will configure auditing. For more ideas about how to use windows logs to spot adversary refer to links in Reference section.
Reference
https://www.nsa.gov/ia/_files/app/spotting_the_adversary_with_windows_event_log_monitoring.pdf
https://zeltser.com/security-incident-log-review-checklist/
https://technet.microsoft.com/en-us/library/dd772712%28v=ws.10%29.aspx
https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/default.aspx
Click to access Windows-Logging-Cheat-Sheet_Sept_2015.pdf
DFIR blog 