hack3rs.ca network-security

/learning/linux-windows-logging-basics-for-defenders :: module-3

student@hack3rs:~/learning$ open linux-windows-logging-basics-for-defenders

Linux and Windows Logging Basics for Defenders

Linux security logging and Windows event logs are the other half of network defense. Knowing which logs exist, what they are actually good for, and how to collect enough data for an investigation — without generating noise you cannot search — is a foundational skill.

A network alert tells you a connection happened. Host logs tell you which process created it, which account owned that process, and what happened next. Without reliable host telemetry, investigations stall at "we saw suspicious traffic" and never reach "here is what ran, here is what changed, here is the account that needs to be disabled." Centralized, consistent host logging is what makes network detections actionable.

learning-objectives

$Identify key Linux and Windows log sources used in basic security investigations.
$Distinguish operational logs from security-relevant telemetry.
$Define a minimum baseline logging set for endpoints and servers.
$Normalize timestamps, hostnames, and user identities across sources.

example-dataflow-and-observation-paths

Trace each step and identify which log or capture point gives you evidence at that stage. Most triage mistakes happen when someone skips a hop and draws conclusions from an incomplete picture.

$User authenticates via SSH -> sshd writes Event ID 4624 equivalent (or auth.log accepted line) with timestamp, source IP, and method -> syslog/journald buffers the event -> log forwarder ships it to SIEM -> analyst sees it in timeline with surrounding context.
$Alert fires on a network connection -> analyst grabs the destination IP and timestamp -> pulls auth.log or Security event log from that host at the same time window -> finds the user and process behind the connection -> triage moves from 'unknown' to a named account and binary.
$NTP syncs the system clock -> event timestamps are written with that reference -> centralized collector ingests with its own timestamp -> delta between the two timestamps tells you how much clock drift to account for in any cross-host sequence.

baseline-normal-before-debugging

$Every SSH login attempt generates a corresponding auth.log or Event ID 4624 entry with a timestamp accurate to within a few seconds of UTC.
$A log forwarder delivers events to the SIEM within 60 seconds of generation; gaps longer than that warrant investigation.
$A sequence of sudo or privilege commands from an admin account appears in auth.log alongside the terminal session that initiated them.

Expert tip: Record what normal looks like in your actual environment before you test any edge case. A baseline you measured beats a baseline you assumed every time.

concept-breakdown-and-mastery

1. Linux Logging Fundamentals

$ core idea: Linux systems log through journald, syslog, or both. For defensive work, the relevant sources are authentication events, sudo and privilege escalation records, SSH activity, service logs, kernel messages, and web server access and error logs. The specific file paths vary by distribution and configuration — always verify in the actual environment rather than assuming standard locations.

$ defender angle: Retention and forwarding matter as much as collection. A log that rotates off the local system before an investigation starts is operationally equivalent to no log. Defenders should know the rotation policy and retention window for every system they are responsible for monitoring.

$ prove understanding: Identify key Linux and Windows log sources used in basic security investigations.

2. Windows Event Logging Fundamentals

$ core idea: Windows exposes multiple event channels: Security, System, Application, PowerShell, and Sysmon if deployed. For defenders, the high-value sources are account logon and logoff events, privilege changes, process creation, scheduled task modifications, and PowerShell execution — especially where script block logging or module logging is enabled.

$ defender angle: Windows logging gets noisy fast. Enabling every available source without a clear analysis plan produces volume that slows queries and buries real signals. Start with a defined set of event IDs tied to specific detection goals. Event IDs alone are not enough — context like parent process, account type, host role, and time of day is what makes them actionable.

$ prove understanding: Distinguish operational logs from security-relevant telemetry.

3. Host Logs + Network Logs = Defensible Investigations

$ core idea: Pair network evidence with host evidence. A connection to a suspicious domain carries more weight when you know which process initiated it, under which account, and whether that behavior matches the account's normal pattern. Network telemetry tells you where; host logs tell you what and who.

$ defender angle: Build a consistent, high-value logging baseline across all critical systems before tuning individual detections. Inconsistent coverage — detailed logging on some hosts but nothing on others — creates blind spots that attackers find and defenders miss.

$ prove understanding: Define a minimum baseline logging set for endpoints and servers.

deep-dive-notes-expanded

Read each section, then immediately test the concept in your lab. Theory that you have not verified with a real command or log line does not stick.

1. Linux Logging Fundamentals

Linux systems log through journald, syslog, or both. For defensive work, the relevant sources are authentication events, sudo and privilege escalation records, SSH activity, service logs, kernel messages, and web server access and error logs. The specific file paths vary by distribution and configuration — always verify in the actual environment rather than assuming standard locations.

Retention and forwarding matter as much as collection. A log that rotates off the local system before an investigation starts is operationally equivalent to no log. Defenders should know the rotation policy and retention window for every system they are responsible for monitoring.

Syslog forwarding to a central collector should be a baseline requirement. Local-only logging on production systems is a single disk failure or adversarial log wipe away from losing all evidence.

Normal Behavior

Every SSH login attempt generates a corresponding auth.log or Event ID 4624 entry with a timestamp accurate to within a few seconds of UTC.

Failure / Abuse Pattern

A host's auth.log has a 45-minute gap during the incident window — the log rotation interval was too aggressive and the file was overwritten before collection.

Evidence To Collect

Identify key Linux and Windows log sources used in basic security investigations.

2. Windows Event Logging Fundamentals

Windows exposes multiple event channels: Security, System, Application, PowerShell, and Sysmon if deployed. For defenders, the high-value sources are account logon and logoff events, privilege changes, process creation, scheduled task modifications, and PowerShell execution — especially where script block logging or module logging is enabled.

Windows logging gets noisy fast. Enabling every available source without a clear analysis plan produces volume that slows queries and buries real signals. Start with a defined set of event IDs tied to specific detection goals. Event IDs alone are not enough — context like parent process, account type, host role, and time of day is what makes them actionable.

Time synchronization is non-negotiable for cross-host investigations. NTP drift of even a few minutes can break timeline reconstruction across multiple machines. Machine name consistency and centralized collection are equally critical.

Normal Behavior

A log forwarder delivers events to the SIEM within 60 seconds of generation; gaps longer than that warrant investigation.

Failure / Abuse Pattern

Event timestamps from two hosts are 7 minutes apart for what appears to be the same activity — one host lost NTP sync and drifted; verify with `timedatectl status`.

Evidence To Collect

Distinguish operational logs from security-relevant telemetry.

3. Host Logs + Network Logs = Defensible Investigations

Pair network evidence with host evidence. A connection to a suspicious domain carries more weight when you know which process initiated it, under which account, and whether that behavior matches the account's normal pattern. Network telemetry tells you where; host logs tell you what and who.

Build a consistent, high-value logging baseline across all critical systems before tuning individual detections. Inconsistent coverage — detailed logging on some hosts but nothing on others — creates blind spots that attackers find and defenders miss.

Document collection gaps explicitly by system role: domain controllers, VPN concentrators, firewalls, jump hosts, application servers, and admin workstations should each have defined logging expectations and verified forwarding paths. A gap list is a risk register for your telemetry.

Normal Behavior

A sequence of sudo or privilege commands from an admin account appears in auth.log alongside the terminal session that initiated them.

Failure / Abuse Pattern

A critical Windows server is not in the SIEM — its Windows Event Forwarding subscription silently failed; WEF subscriptions need regular health checks.

Evidence To Collect

Define a minimum baseline logging set for endpoints and servers.

terminal-walkthroughs-with-example-output

Each walkthrough shows a command and what useful output looks like. Your lab output will differ — focus on which fields to read, not on matching the exact values shown here.

Linux Logging Basics

Beginner

Command

journalctl -n 100 --no-pager

Example Output

... sshd[1234]: Accepted publickey for analyst
... sudo: analyst : COMMAND=/usr/bin/systemctl status ssh

$ why this matters: Run this against your lab environment and read the output field by field before moving on to the next command in this block. If you cannot explain what you see, re-read the section on linux logging basics.

Windows Event Log (PowerShell)

Intermediate

Command

Get-WinEvent -LogName Security -MaxEvents 20

Example Output

TimeCreated              Id  ProviderName
-----------              --  ------------
...                      4624 Microsoft-Windows-Security-Auditing

Cross-Source Timeline Prep

Advanced

Command

timedatectl status

Example Output

# command executed in lab
# review output for expected fields, errors, and anomalies

cli-labs-and-workflow

Run these in a lab VM or network segment you own or are authorized to test against. After each command, write down one thing the output told you that you did not already know.

Linux Logging Basics

Beginner

journalctl -n 100 --no-pager
journalctl -u ssh --since '1 hour ago'
sudo tail -f /var/log/auth.log
sudo grep -i 'failed' /var/log/auth.log | tail

Run in a lab or authorized environment. Record what fields change when you alter the test conditions.

Windows Event Log (PowerShell)

Intermediate

Get-WinEvent -LogName Security -MaxEvents 20
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} -MaxEvents 10
Get-WinEvent -LogName Microsoft-Windows-PowerShell/Operational -MaxEvents 20

Run in a lab or authorized environment. Record what fields change when you alter the test conditions.

Cross-Source Timeline Prep

Advanced

timedatectl status
hostnamectl
date -u

Run in a lab or authorized environment. Record what fields change when you alter the test conditions.

expert-mode-study-loop

$Explain the concept out loud as if briefing a colleague — no notes.
$Pick one CLI command and walk through exactly what the output means field by field.
$Name a specific failure mode and the log line or packet flag that reveals it.
$Write down what normal looks like for your lab before you introduce any anomaly.

Progress marker: Move on when you can brief the topic to someone else, run the commands from memory, and explain what a bad result looks like.

knowledge-check-and-answer-key

Answer each question out loud or in writing before you look at the hints. If you cannot answer it, go back to the section that covers it — do not just read the hint and move on.

1. Linux Logging Fundamentals

Questions

?How would you explain "Linux Logging Fundamentals" to a new defender in plain language?
?What does normal behavior look like for linux logging fundamentals in your lab or environment?
?Which logs, packets, or commands would you use to validate linux logging fundamentals?
?What failure mode or attacker abuse pattern matters most for linux logging fundamentals?

Show answer key / hints

Answer Key / Hints

#Identify key Linux and Windows log sources used in basic security investigations.
#Every SSH login attempt generates a corresponding auth.log or Event ID 4624 entry with a timestamp accurate to within a few seconds of UTC.
#journalctl -n 100 --no-pager
#A host's auth.log has a 45-minute gap during the incident window — the log rotation interval was too aggressive and the file was overwritten before collection.

2. Windows Event Logging Fundamentals

Questions

?How would you explain "Windows Event Logging Fundamentals" to a new defender in plain language?
?What does normal behavior look like for windows event logging fundamentals in your lab or environment?
?Which logs, packets, or commands would you use to validate windows event logging fundamentals?
?What failure mode or attacker abuse pattern matters most for windows event logging fundamentals?

Show answer key / hints

Answer Key / Hints

#Distinguish operational logs from security-relevant telemetry.
#A log forwarder delivers events to the SIEM within 60 seconds of generation; gaps longer than that warrant investigation.
#Get-WinEvent -LogName Security -MaxEvents 20
#Event timestamps from two hosts are 7 minutes apart for what appears to be the same activity — one host lost NTP sync and drifted; verify with `timedatectl status`.

3. Host Logs + Network Logs = Defensible Investigations

Questions

?How would you explain "Host Logs + Network Logs = Defensible Investigations" to a new defender in plain language?
?What does normal behavior look like for host logs + network logs = defensible investigations in your lab or environment?
?Which logs, packets, or commands would you use to validate host logs + network logs = defensible investigations?
?What failure mode or attacker abuse pattern matters most for host logs + network logs = defensible investigations?

Show answer key / hints

Answer Key / Hints

#Define a minimum baseline logging set for endpoints and servers.
#A sequence of sudo or privilege commands from an admin account appears in auth.log alongside the terminal session that initiated them.
#timedatectl status
#A critical Windows server is not in the SIEM — its Windows Event Forwarding subscription silently failed; WEF subscriptions need regular health checks.

lab-answer-key-expected-findings

These are reference answers for a generic environment. Replace them with observations from your own lab — what you measured yourself is more useful than what is written here.

Expected Normal Findings

+Every SSH login attempt generates a corresponding auth.log or Event ID 4624 entry with a timestamp accurate to within a few seconds of UTC.
+A log forwarder delivers events to the SIEM within 60 seconds of generation; gaps longer than that warrant investigation.
+A sequence of sudo or privilege commands from an admin account appears in auth.log alongside the terminal session that initiated them.

Expected Failure / Anomaly Clues

!A host's auth.log has a 45-minute gap during the incident window — the log rotation interval was too aggressive and the file was overwritten before collection.
!Event timestamps from two hosts are 7 minutes apart for what appears to be the same activity — one host lost NTP sync and drifted; verify with `timedatectl status`.
!A critical Windows server is not in the SIEM — its Windows Event Forwarding subscription silently failed; WEF subscriptions need regular health checks.

hands-on-labs

$Generate a test SSH login and failed login on Linux and locate the related records.
$Generate a Windows test logon and a PowerShell command, then identify relevant Event IDs/channels.
$Map one network alert to host logs to identify process/user/source of activity.

common-pitfalls

$No time sync (NTP) leading to broken timelines.
$Collecting logs without retention or centralization.
$Turning on verbose logging everywhere without a parsing/search plan.

tools-and-references

completion-outputs

# A baseline host logging checklist by OS and role
# A simple timeline worksheet combining host and network events
# A gap list for systems missing centralized logging

related-threat-pages

See where these fundamentals appear in real attack scenarios and what evidence defenders look for during triage.

open /threats/insider-threat-and-privilege-misuse Insider threat and privilege misuse open /threats/lateral-movement-after-initial-access Lateral movement after initial access

<- previous page Subnetting, NAT, Firewall Policy Logic, and Segmentation Basics -> next page Packet Capture and Protocol Analysis with Wireshark / TShark

learning-path-position

Foundations / Weeks 1-2 · Module 3 of 12