Security Operations Platform arrow_forward expand_more
Solutions arrow_forward expand_more
Why Chronicle arrow_forward expand_more
Why Chronicle

Rely on a modern approach to threat detection and response.

Why Chronicle
Partners arrow_forward expand_more
Resources arrow_forward expand_more
Security Operations Platform arrow_forward expand_more
Solutions arrow_forward expand_more
Why Chronicle arrow_forward expand_more
Why Chronicle

Rely on a modern approach to threat detection and response.

Why Chronicle
Partners arrow_forward expand_more
Resources arrow_forward expand_more
IDC Study: Customers cite 407% ROI with Google Chronicle. Learn More IDC Study: Customers cite 407% ROI with Google Chronicle. .
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!

LINUX LOGS

LOCATION

DESCRIPTION

MITRE ATT&CK (SUB)TECHNIQUE

/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

WINDOWS LOGS

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 Visit the contact us page