Logs your SOC can use every day: a quick reference guide

Here’s your copy of a helpful log guide to make life easier for analysts.

As you can imagine, the Expel security operations center (SOC) uses a lot of logs. So we pulled them all together into a handy quick reference guide for our analysts. Then we decided it might be nice if we shared the list with our readers.

Enjoy.

What SOC logs are and where to start

A log is a timestamped record of something a system did—a request served, a user authenticated, a scheduled job run, a file written. On its own, a single line is inert. In an investigation it’s evidence: the record that puts an action at a time, on a host, under an account.

Security teams lean on logs for two jobs that pull in different directions. Detection needs a narrow, high-signal subset arriving fast enough to alert on. Investigation needs breadth and history—the log you didn’t think mattered until you’re reconstructing how someone got in. Most log strategies fail by optimizing for one and forgetting the other.

Which log sources to prioritize

If you’re starting from nothing, work in this order:

1. Identity and authentication. Who logged in, from where, and whether it worked. Windows Security event log, Linux auth logs, and your identity provider. Most intrusions touch these first.
2. Endpoint. Process execution, and the shell history covered below. This is where you see what an attacker actually did.
3. Cloud control plane. API calls against your cloud accounts—who created, changed, or deleted infrastructure.
4. Web access. The first thing you reach for when a public-facing server is compromised.
5. Everything else. Useful in an investigation, rarely worth alerting on.

Work backward from the detections you want rather than forward from what’s easy to collect. A SIEM full of the logs that were simplest to onboard tells you about the wrong parts of your environment.

Retention and ingestion basics

Two costs govern every logging decision. Ingestion is what you pay to get data into your SIEM, usually priced by volume—which means your bill scales with how much you log, not how much you detect. Retention is what you pay to keep it, and it’s governed as much by compliance as by security: PCI DSS requires 12 months of audit log history with three months immediately available, and other frameworks set their own floors.

That tension is why teams increasingly split the difference—high-signal sources into the SIEM where detections run, high-volume low-signal sources into a security data lake where storage is cheaper and the data stays queryable for investigations. Before adding sources, it’s worth knowing whether the problem is coverage or tuning; optimizing an existing SIEM is often cheaper than feeding it more.

One practical note for everything below: default paths are defaults, not guarantees. Every section includes where to find the config file when logs aren’t where they should be.

Web access logs

Access logs record the http web requests sent to a web server. They’re the first logs we reach for in the event of a web server compromise. These logs show critical investigate information, like the URI string of requests, the status code of the request (200, 404, 500, etc.), and the requester’s source IP.

Finding web access logs in non-default locations

Logging can be configured to write anywhere. When logs aren’t at the default path, the config file tells you where they went.

A note on IIS and multiple app pools: The app pool you want is in the command line arguments of the W3WP.exe process you’re investigating. Once you have the site id from applicationHost.config, the logs for that pool sit at <log-directory>\W3SVC<id-number>. Under the hood Confluence uses a Tomcat server, so its logging config works the same way Tomcat’s does.

Windows event logs

Windows event logs can be a treasure trove of forensic information. The security event log Security.evtx is one of the most-used log files in the Expel SOC, but other log files like System.evtx and Application.evtx can sometimes be put to good use.

Security.evtx holds a lot of valuable information, but one of the most common reasons for collecting this log is to get authentication info from event IDs 4624 and 4625. Authentication events are the highest-value logs most teams collect—see what a security operations center does with them.

Browser history files

Browser history files can be used to determine what website a malicious file was downloaded from (if it was downloaded through a browser). EDR tools and firewalls don’t always capture the URL or domain name that a file was downloaded from, but browser history is an easy way to determine where a user got a file.

Browser history files are simple SQLite databases that can be opened in free tools like DB Browser for SQLite (DB4S).

Linux logs

Linux can seem a bit scary and complex to investigate, but when it comes to logging, it’s actually pretty simple. You don’t need any special software—all of these files can be opened in a text editor. These feed the same detection pipeline as everything else; the role SIEM plays in security operations covers how they get there.

Cron is the main scheduling tool that attackers might use to establish persistence on a Linux system. Cron logs can seem a bit superfluous—given that cron is often logged to the syslog/messages log—but like everything in Linux, cron logging can be highly configured. If you don’t see cron logs in the syslog, then it may be worth checking the dedicated cron log.

Shell history logs

Shell history logs are one of the most valuable investigative logs when it comes to Linux systems. Shell history records user-run commands and, given how command line heavy Linux can be, it’s likely that shell history will record at least some of the actions taken by an attacker.

These files are hidden by default, so make sure you enable hidden files when searching for them.

References

Apache logs

• https://www.loggly.com/use-cases/how-to-monitor-your-apache-logs/
• https://sematext.com/blog/apache-logs/#apache-access-logs-location
• https://exampleconfig.com/view/apache-ubuntu20-04-etc-apache2-sites-available-000-default-conf
• https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/html/deployment_guide/s1-apache-config
• https://httpd.apache.org/docs/2.4/platform/windows.html

Tomcat logs

• https://www.loggly.com/use-cases/monitoring-and-troubleshooting-tomcat-logs/
• https://linuxhint.com/view-tomcat-logs-linux/
• https://sematext.com/blog/tomcat-logs/#:~:text=Tomcat%20Logs%20Location,-The%20location%20of&text=log%20.,%7Bver%7D%5Clogs%5Ccatalina.

JBOSS logs

• https://access.redhat.com/documentation/en-us/red_hat_jboss_data_virtualization/6.2/html/administration_and_configuration_guide/default_log_file_locations
• https://docs.cyberark.com/AAM-CP/10.10/en/Content/CP%20and%20ASCP/Logging-in-JBoss.htm

Confluence logs

• https://confluence.atlassian.com/doc/configure-access-logs-1044780567.html
• https://support.atlassian.com/organization-administration/docs/configure-required-connections-and-upstream-ports/

Nginx logs

• https://docs.splunk.com/Documentation/AddOns/released/NGINX/Setupv2#:~:text=By%20default%2C%20the%20access%20log,%2Fetc%2Fnginx%2Fnginx.

Browser history

• https://www.foxtonforensics.com/browser-history-examiner/chrome-history-location
• https://www.foxtonforensics.com/browser-history-examiner/microsoft-edge-history-location
• https://www.foxtonforensics.com/browser-history-examiner/firefox-history-location
• https://www.foxtonforensics.com/blog/post/analysing-safari-browser-history

Linux logs

• https://www.plesk.com/blog/featured/linux-logs-explained/
• https://man.freebsd.org/cgi/man.cgi?syslog.conf(5)
• https://man.freebsd.org/cgi/man.cgi?query=cron&apropos=0&sektion=0&manpath=SunOS+5.9&format=html