Security Operations Suite arrow_forward expand_more
Solutions arrow_forward expand_more
Why Chronicle arrow_forward expand_more
Resources arrow_forward expand_more
Security Operations Suite arrow_forward expand_more
Solutions arrow_forward expand_more
Why Chronicle arrow_forward expand_more
Resources arrow_forward expand_more
Your security operations cheat sheet for Windows and Linux logs (and how to tie them to the MITRE ATT&CK Framework)

Within the security operations center, visibility is everything. Being aware of the details of users, assets, known threats, and specific vulnerabilities present across security, network, server, application and database sources allows security operations teams to act quickly and decisively to address possible risks.

Here is where Linux and Windows event logs come in, providing that essential observability into the goings-on across your organization’s network and digital footprint. But it is not always easy for teams to know where they should be looking. That’s because your logs are likely capturing huge volumes of data. Knowing which events are indicative of something major and worthy of further investigation, like a security breach, isn’t always self-evident.

That is why Google Cloud Technical Solutions Engineer Ivan Ninichuck compiled the below cheat sheet of go-to Windows and Linux logs and and mapped them to key tactics and techniques of the MITRE ATT&CK framework. This will allow your security operations team to know which log files are critical for activities such as monitoring, auditing, analysis, threat hunting, and overall security program improvement.

Keep this list handy, especially if your SOC’s maturity level needs a little boost!


/var/log/messages(debian /var/log/syslog) Stores all global system activity data, including startup messages T1133: External Remote Services
/var/log/secure(debian /var/log/auth.log) Security-related events such as user logins, root user activity and PAM output T1078.001: Default Locations
/var/log/kern.log Contains errors, events and warning logs T1543: Systemd Service
/var/log/cron Scheduled tasks (optimal for identifying persistence) T1053.003: Cron
/var/log/faillog Failed logon attempts T1110.001: Brute Force Password Guessing
/var/log/wtmp Contains all login and logout events T1078.001: Default Locations
/var/log/audit/audit System logs designed to record security events for incident investigation T1543: Systemd Service


C:\WINDOWS\system32\config\ This location is the storage point for the Windows event logs. These logs cover everything from system logs to security logs to application and service logs. For the purpose of this cheat sheet, we will break them down into categories in the following rows. Windows event logs can be used to investigate any MITRE ATT&CK technique applicable to the Windows OS.
Application Log Any event logged by an application. T1610: Deploy Container
System Log Any event that the operating system logs based on both normal and abnormal operations. T1543.003: Create or Modify System Process-Windows Service
PowerShell Log A special set of event logs in the ‘Application and Services’ section record all activity undertaken using the PowerShell scripting language T1059.001: PowerShell Scripting
Sysmon Log A special set of logs can be added in the ‘Application and Services’ by installing the Sysinternal tool Sysmon. It provides alerting based on key security events beyond that offered by the security log. T1574.002: DLL-Sideloading
Security Log All security events are logged in this category. Examples include valid/invalid logins, file deletions, registry changes and several others. T1037.001: Boot or Logon Initialization Script
Directory Service Log If the Windows OS is a domain controller, then Active Directory logs are located in this category. T1556.001: Domain Controller Authentication
DNS Server Log If the Windows OS is acting as a DNS server then all logs for that Service are kept under this section. T1071.004: Exfiltration over Application Layer Protocol: DNS
File Replication Service Log If the Windows OS is acting as a domain controller then all replication logs are kept under this section. T1556.001: Domain Controller Authentication

Certain tools can help you collect, centralize and interpret the log data. SIEMs, for example, help to “connect the dots” about potential incidents by correlating events from these different sources, generating alerts for analysts about potentially malicious activity happening within the network.

It is that last step – generating alerts for analysts – that creates the need for something more. Given the manual-intensive, time-consuming and repetitive nature of alerts, several ramifications can result, including analysts being overwhelmed by their sheer volume. This can result in poor outcomes, like missing something important or even burning out.

For maximum effectiveness, you can connect your SIEM systems (or other detection tools like EDR, NDR, anti-phishing, DLP and CASBs) to a security orchestration, automation and response (SOAR) platform, which will address the alerts.

SOAR helps to streamline the management of security issues through automated playbooks, manage disparate detection tools through a single interface and coordinate responses to security incidents.

Let’s work together
Ready for Google-speed threat detection and response?
Contact us