Did you know that you may identify 275 MITRE Framework techniques if you have enabled the Command Execution log? Not at all surprising, huh? Ironically, by default, command execution logs are not configured.
Have you ever found significant gaps in logging capability while doing an incident response or conducting a threat hunt? For instance, you were requested to look into a compromise where it appears that the attackers may have hidden PowerShell code or employed fileless malware. You can locate instances of Powershell.exe and CMD.exe when you investigate, but you are unable to determine what was really performed. Why? since it is not configured by default, as was previously stated.
NOTE: As per the following source and with what we have seen roughly 70% of the Desktop OS is Windows. Also, it can be read in multiple sources that 90% of the Fortune 10000 companies use Active Directory, so we will be focusing on Windows. Reference: Active Directory Holds the Keys to your Kingdom, but is it Secure?
Why the logging problem exists
In the enterprise environment the number of devices (servers, workstations etc.) can be in the thousands. These many devices generate hundreds of gigabytes of default logs on a daily basis. Then, for the compliance and regulatory checks, they must maintain the log backups of at least past 90 days. If we do the math, we are talking about TBs of data. These logs in majority of case are stored in the cloud. This contributes to significant costs.
The cost and storage will rise significantly if we add more logs or enable more logs. However, if we can demonstrate the business case and the benefits—which include improved visibility and a higher likelihood of identifying or receiving an alert in real time—we are still able to enable more logs (provided SIEM is fine-tuned).
Solution?
Now that we know the problem, let’s talk about solution. There are numerous log sources that can be enabled in Windows. What all do we need to enable? Instead of naming them like Network Logs, Application Logs, System Logs etc., let's be a bit specific.
DeTTECT, an open-source tool, is the ideal way for us to find out this information. There are specifically two advantages to it:
- Being aware of which MITRE Technique requires particular log source.
- Current MITRE TTPs detection in environment as per the log sources enabled.
We can find the Important Log Sources and its relative technique using this tool.
Log Sources - 1
Log Sources - 2
Here you can find the exact number (count) of TTP, which can be detected with the log source mentioned after it. We see Command Execution Log will help in detecting 275 techniques, Process Creation Log will help in detecting 237 techniques and so on. This gives us a clear picture of what log needs to be prioritized when it comes to enabling.
Will we be turning on all of the logs that are included in DeTTeCT?
Not quite; it relies on the enterprise, their industry, and their location. We have an open source tool called Control Validation Compass, which is a little out of date but still a nice place to start. This shows the threat or top technique that APT groups are using to target a particular industry in a particular region.
Let's use the example of a UK-based chemical company that want to focus its spending and efforts in order to gain more visibility in terms of logs.
Now we'll map this option in Control Validation Compass:
Control Validation Compass - Threat Model
If you click the Down arrow on Lookup by victim industry, you can select the industry.
Control Compass Validation - Adversary TTP
As you select, you see APT Groups showing on the right side. There either you can select Entire Threat Category [Chemical (All Adversary)] or Specific Groups. Let’s select All Adversaries. Scroll down and you will see a heatmap getting generated showing all the techniques on should focus on as priority.
Control Compass Validation - Heatmap
Now that we know what log sources needs to be enabled for prioritized TTPs. Next part is from where to enable them? The answer is GPO - Group Policy (focusing on Windows OS).
Basic Logging
Since we have Command Execution as a must log source, we will enable it first.
We know command in windows can be executed in Command Prompt and PowerShell. Therefore, we will enable logs for these.
Search for 'Edit Group Policy' or press Win+R and type 'gpedit.msc'. This will open your Local Group Policy Editor.
Group Policy
- Command Prompt / Command Line Logs
Inside Local Group Policy Editor move traverse the following-
Computer Configuration -> Administrative Template -> System -> Audit Process Creation
Command Line Log
Double-click on Include command line in process creation events and you will get this pop-up.
Enabling the Command Line Log
Select Enabled then Apply and OK to save it. That's it, now we can see Command Prompt entries in logs.
We now have to enable the Process Creation Log in Advanced Audit Policy, which we have covered in depth later in this blog. As of now, traverse to the following path in group policy and enable the log as shown.
Computer Configuration -> Windows Settings -> Security Settings -> Advanced Audit Policies -> System Audit Policy - Local Group -> Detailed Tracking -> Audit Process Creation.
Choose the Configure the following audit events and then choose both, Success and Failure. Apply the settings.
Advanced Audit Policy - Process Creation Log
How to identify events generated by enabling this log source
Every log generated has an Event ID associated with it. For Command Line, the Event ID is 4688.
- PowerShell Logs
Inside Local Group Policy Editor move traverse the following:
Computer Configuration -> Administrative Template -> Windows Component -> Windows Powershell.
PowerShell Log
Here, we have to focus on:
- Turn on Module Logging
PowerShell - Module Logging
- Turn on PowerShell Script Block Logging
PowerShell - Script Block Logging
With this we will have PowerShell Logs enabled.
Optional: You may also enable Turn On PowerShell Transcription.
PowerShell - Transcription
How to identify events generated by enabling this log sources?
- Module logging events can be found in Event ID 4103.
- Script Block Logging events can be found in Event ID 4104.
- PS Transcription generates text file in the Output folder provided.
Reference: 
Advanced Logging - Advanced Audit Policy
Before we jump into where to enable these, let's have a look at what they are, as there is already Basic Audit Policy.
As per Microsoft Documentation -
“There are nine basic audit policy settings under Security Settings\Local Policies\Audit Policy and settings under Advanced Audit Policy Configuration. The settings available in Security Settings\Advanced Audit Policy Configuration address similar issues as the nine basic settings in Local Policies\Audit Policy, but they allow administrators to be more selective in the number and types of events to audit. For example, the basic audit policy provides a single setting for account sign-in, and the advanced audit policy provides four. Enabling the single basic setting would be the equivalent of setting all four advanced settings. In comparison, setting a single advanced audit policy setting doesn't generate audit events for activities that you aren't interested in tracking.”
In short, Advanced Audit Policy allows the Administrator to be more selective in terms of logging, which eventually helps in preventing excessive storage requirement.
These Policies can be found in
Computer Configuration -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration.
Advanced Audit Policy
Inside Advanced Audit Policy the Logs are grouped as per their characteristic, Account Logon, Account Management etc. On clicking them, we will get the Policies that can be enabled. (For Example – Logon/Logoff)
Advanced Audit Policy - Example - Logon/Logoff
If we click any one of the options:
Advanced Audit Policy - Example - Audit Special Logon
Here we can configure where we want to logs for success, failure or both. In case you are not aware what the Property does, simply clicking on the Explain tab will show a brief description of it.
Audit Special Logon
How to identify events generated by enabling this log source?
BONUS: Microsoft Documentation has covered these Properties in depth, providing information like which type (Domain Controller/Workstation) these events can be seen, what event IDs are associated with the property etc. For reference, Audit Special Logon - Audit Special Logon - Windows 10
For other log sources / properties, Event ID can be found in documentation here.
Wouldn't it be great if somehow, we could know the best practice or recommendations on what Logs need to be enabled selectively.
Well, Microsoft does have a detailed documentation on the best practices covering the Default Settings, Recommended Settings and Strong Recommendations in terms of logging.
For reference:
Best Practices and Recommendations
Similarly for every other Policy, a table can be found here - Audit Policy Recommendations
Good to know Event IDs
- 4624 - An account successfully logged on
- 4625 - An account failed to logon
- 4648 - A logon was attempted using explicit credentials
- 4688 - A new process has been created
- 4698 - A scheduled task was created
- 4720 - A user account was created
- 4768 - A Kerberos authentication ticket (TGT) was requested
- 4769 - A Kerberos service ticket was requested
Conclusion
In summary, knowing what log data to collect and where to collect it from is essential for gaining a comprehensive view of your environment, which in turn enhances security, performance monitoring, and operational decision-making. By doing this, we may detect the adversaries early on and prevent possible damage they can do. Not all log sources needs to be enabled, with proper priority and understanding of threat landscape, an optimal state can be find where we have enough log sources without having a burden of storage and its incurring cost.
Lastly, when every log source is enabled, you can verify them by the Event IDs. Here is one of the best resource for this - Windows Security Log Encyclopedia
References
- MITRE Framework Enterprise Matrix
- MITRE Data Sources
- MITRE DeTTeCT
- Control Validation Compass
- Advanced Audit Policy FAQs
- Audit Policy Recommendation
- Threat Hunting: Fileless Malware Detection - Event IDs
About SBT
Security Blue Team is a leading online defensive cybersecurity training provider with over 100,000 students worldwide, and training security teams across governments, military units, law enforcement agencies, managed security providers, and many more industries.