Week 2: SOC Odyssey-Understanding Windows Event IDs and Linux Log Hunt

Week 1 was about SOC operations and alert triage. In Week 2, we continued building our SOC skills through a webinar and practical challenges covering Windows Event IDs and Linux log analysis. As Arianda settles into her SOC journey, it is time to understand where logs come from, how to find them, and how they can help an analyst investigate suspicious activity. Let's get into it!

Part 1: Understanding Windows Event IDs

During the webinar, we explored how Windows records events and how analysts can use Event Viewer to investigate system activity. First, what exactly is a log?

A log is a record of events or activities that happen on a computer or within an application. These events can include successful logins, failed authentication attempts, system changes, and application errors. Not every action generates a log, but the events that are recorded can provide useful evidence during an investigation. In Windows, we use Event Viewer to view and investigate these records. Windows organizes events into different logs, including:

Application: Events recorded by applications.
Security: Events related to security activity, such as logons and access attempts.
Setup: Events related to Windows installation and setup.
System: Events recorded by Windows system components and services.
Forwarded Events: Events collected from other computers.

Each event has an Event ID that helps identify the type of activity recorded. For example, Event ID 4624 records a successful logon, while Event ID 4625 records a failed logon.

I also learned how to filter events in Event Viewer to find specific activities, such as successful and failed authentication attempts, instead of going through every event manually.

What is Sysmon?

We also looked at Sysmon (System Monitor), a Windows system monitoring tool from Microsoft Sysinternals that records detailed system activity in Windows Event Logs. Sysmon provides additional visibility that can help SOC analysts investigate suspicious behaviour. Some useful Sysmon Event IDs include:

Event ID 1-Process Creation: Records when a process is created.
Event ID 3-Network Connection: Records network connections made by a process when this event type is enabled in the configuration.
Event ID 11-File Creation: Records when a file is created.

These events can help an analyst investigate what a program executed, which files it created, and whether it made network connections. One thing to remember is that Sysmon's visibility depends on its configuration. Not every event type is necessarily recorded on every system.

Part 2: Linux Log Hunt

After Windows, we moved to Linux logs. This was another opportunity to understand how analysts can investigate authentication attempts, system activity, web requests, and other events using the command line. One thing I learned is that Linux log locations can differ depending on the distribution. Ubuntu and Debian commonly use /var/log/auth.log for authentication events, while CentOS and RHEL commonly use /var/log/secure.

We also practised using commands to search through log files.

For example:

grep "Failed password" /var/log/auth.log

grep "Failed password" /var/log/auth.log

This searches for entries containing Failed password, which can help identify failed SSH authentication attempts.

To search without worrying about uppercase or lowercase letters, we can use:

grep -i "failed" /var/log/auth.log

grep -i "failed" /var/log/auth.log

If I want to narrow the results further and look for entries containing a particular username, I can pipe the output into another grep command:

grep "Failed password" /var/log/auth.log | grep "analyst"

grep "Failed password" /var/log/auth.log | grep "analyst"

This searches for failed-password entries that also contain the word analyst.

I also learned to list files and view their sizes using:

ls -lh /var/log

ls -lh /var/log

The -l option displays a detailed listing, while -h displays file sizes in a human-readable format.

Another command we explored was journalctl. On systems that use systemd, it allows us to query the system journal, which stores logs from system services and other sources.

For example:

sudo journalctl -u sshd

sudo journalctl -u sshd

This displays journal entries for the sshd service. Depending on the Linux distribution, the service may instead be named ssh.

These commands helped me understand that log analysis is not just about reading everything on the screen. It is also about knowing how to narrow down the results and find information relevant to an investigation.

Part 3: Practical Challenge-A SOC Odyssey: Windows Event IDs

Now, let's get into the practical side! The A SOC Odyssey-Windows Event IDs challenge focused on identifying suspicious activities on Windows workstations and understanding which event logs can help a SOC analyst investigate an incident.

Here are some of the key things I learned.

1. Successful Logons-Event ID 4624

Event ID 4624 records successful logons. When investigating possible unauthorized access, an analyst can examine the logon type, account details, timestamp, and available source information to understand how someone accessed the system. A successful logon does not automatically mean something malicious happened. The analyst needs to establish whether the activity was expected or suspicious.

2. File Creation-Sysmon Event ID 11

Sysmon Event ID 11 records file creation events. This can help an analyst identify files created on a workstation, including their names and paths. It is especially useful when investigating suspicious executable files or files that may have been dropped onto a system.

3. File-System Object Access-Event ID 4663

What if Sysmon is not installed? Windows Security Event ID 4663 can help an analyst investigate access to a file or another object, provided Object Access auditing is enabled, and an appropriate System Access Control List (SACL) is configured. This taught me that there can be other sources of evidence, but the required auditing settings must be in place for the relevant events to be recorded.

4. Windows Defender Malware Detection-Event ID 1116

Windows Defender Operational Event ID 1116 indicates that Microsoft Defender Antivirus has detected malware or another potentially unwanted threat. This event can help an analyst investigate what was detected and determine what additional information is needed to understand the incident.

5. System Shutdown or Restart-Event ID 1074

Event ID 1074 records when a process or user initiates a system shutdown or restart. During an investigation, this can help an analyst establish a timeline and understand whether a system restart was expected or needs further investigation.

My Key Takeaway

This challenge helped me understand that Windows Event IDs are more than just numbers. They provide evidence that can help SOC analysts reconstruct activity, investigate suspicious behaviour, and build an incident timeline. I am continuing to strengthen my understanding of Windows logs and how they support security monitoring and incident response. Every challenge is another opportunity to learn, investigate, and think more like a SOC analyst.

As part of strengthening my Security Operations Centre (SOC) skills, I also completed the Linux Log Hunt challenge, which involved 17 scenario-based questions covering Linux logging, authentication events, web server activity, privileged commands, and scheduled tasks.

The challenge helped me understand that investigating a security incident is not just about spotting suspicious activity. It also involves knowing where to find the relevant logs, interpreting the information they contain, and correlating events to establish what might have happened.

Here are some of the key lessons I took away from the challenge.

1. Linux Log Locations

Linux log locations vary by distribution. Some common examples include:

/var/log/auth.log-Authentication logs on Ubuntu/Debian.
/var/log/secure-Authentication logs on CentOS/RHEL.
/var/log/syslog and /var/log/messages-General system logs.
/var/log/apache2/access.log and /var/log/nginx/access.log-Web server access logs.
/var/log/cron-Cron activity on many CentOS/RHEL systems.
/var/log/audit/audit.log-Security audit events.

I also learned to use journalctl to view systemd journal logs; for example,sudo journalctl -u sshd to check SSH service activity.

2. Investigating Suspicious SSH Activity

One scenario involved a failed SSH login for an invalid user followed by a successful password authentication from the same IP. This taught me to correlate authentication events rather than analyse them individually. Although this pattern warrants investigation, it does not automatically prove an attack or compromised account.

3. Investigating Privileged Commands

Another scenario involved a user running cat /etc/shadow with sudo. Since this file contains local account password hashes and password-aging information, accessing it with elevated privileges is security-relevant.

I learned to examine the user, executed command, and surrounding events to determine whether the activity was expected or suspicious.

4. Analysing Web Server Logs

Apache and Nginx access logs help analysts investigate HTTP requests, including source IP addresses, requested paths, timestamps, and status codes.

For example, a request to /admin/login.php returning 200 OK means the server successfully responded to the HTTP request. It does not necessarily mean the user logged in successfully. Additional evidence may be needed to confirm that.

I learned that cron logs can help identify scheduled commands that may indicate legitimate maintenance or potential persistence. Analysts should examine the job, its owner, and the command it executes before concluding.

I also explored the last command, which displays historical login-session information from records commonly stored in /var/log/wtmp. This can help correlate previous sessions with other authentication logs.

Overall, the Linux Log Hunt taught me to identify the right log source, extract relevant details, and correlate events before deciding whether activity is suspicious.

Key Takeaways from the Linux Log Hunt

The biggest lesson from this challenge was the importance of knowing where to look, understanding what a log entry tells you, and correlating evidence before concluding. I am learning to approach investigations systematically:

Identify the relevant log source.
Extract key details such as timestamps, usernames, IP addresses, commands, and status codes.
Correlate related events across different log sources.
Distinguish suspicious activity from confirmed malicious activity.
Document findings and identify what additional evidence is needed.

Completing the Linux Log Hunt challenge strengthened my understanding of Linux logging and gave me a clearer foundation for investigating authentication attempts, privileged access, web requests, and potential persistence.

My takeaway: Logs are more useful when we connect them. A single event may provide only part of the story, but correlating multiple sources can help a SOC analyst build a clearer picture of what happened.

Wrapping Up Week 2

And that is Week 2!

Between the webinar, the Windows Event IDs challenge, and the Linux Log Hunt, I have learned more about where to find logs, how to filter them, and how to use them as evidence during an investigation.

I still have a lot to learn, but I am beginning to understand how SOC analysts use logs to investigate activity rather than simply looking at alerts and assuming the worst.

One step at a time, one log at a time. That is how we learn!

Stay tuned for Week 3 sessions and labs. 😊

Contents