GO KALI FREE
AdvancedSecurity Operations

Log Analysis: Extracting Intelligence from System Logs

Master log analysis techniques for security operations covering Windows Event Logs, Syslog, Apache logs, DNS logs, and cloud service logs with practical querying and correlation examples.

#Log Analysis#Windows Event Logs#Syslog#Security Monitoring#Forensics

Why Log Analysis Matters

Logs record every significant event in an IT environment. System logs track user authentication, process execution, network connections, file access, and configuration changes. Security professionals analyze logs to detect attacks, investigate incidents, troubleshoot issues, maintain compliance, and understand normal behavior to detect anomalies.

Prerequisites

  • **Networking Basics** — Understanding of protocols and network devices
  • **Linux Commands** — Command line text processing
  • **SIEM Fundamentals** — Understanding of log aggregation
  • Windows Event Logs

    Key Event Logs

    Security Log: Records authentication events, privilege use, and object access.

  • 4624 — Successful logon
  • 4625 — Failed logon
  • 4634 — Logoff
  • 4672 — Special privileges assigned
  • 4688 — Process creation
  • 4698 — Scheduled task creation
  • 4720 — User account created
  • 4732 — User added to security-enabled group
  • System Log: Records system events from services, drivers, and hardware.

    Application Log: Records events from applications.

    PowerShell Log: Script block logging (Event ID 4104) when enabled.

    Analyzing Windows Logs

    # Query last 10 security logon events
    Get-WinEvent -LogName Security -MaxEvents 10 | Where-Object { $_.Id -eq 4624 }
    
    # Find failed logon attempts in last 24 hours
    Get-WinEvent -LogName Security -FilterXPath "*[System[EventID=4625]]" | 
        Where-Object { $_.TimeCreated -gt (Get-Date).AddDays(-1) } |
        Group-Object { $_.Properties[5].Value } |
        Sort-Object Count -Descending
    
    # Export logs for analysis
    wevtutil epl Security security_export.evtx
    

    Key Event Fields

    Each Windows event contains:

  • **TimeCreated**: When the event occurred
  • **EventID**: Identifies the event type
  • **TargetUserName**: The account involved
  • **IpAddress**: Source IP address (for logon events)
  • **ProcessId/ProcessName**: The process generating the event
  • **LogonType**: Interactive (2), Network (3), Batch (4), Service (5), Unlock (7)
  • Linux Syslog

    Key Log Files

    /var/log/auth.log     - Authentication events (Debian/Ubuntu)
    /var/log/secure       - Authentication events (RHEL/CentOS)
    /var/log/syslog       - General system messages
    /var/log/kern.log      - Kernel messages
    /var/log/apache2/     - Apache web server logs
    /var/log/nginx/       - Nginx web server logs
    

    Analyzing Linux Logs

    # Find failed SSH login attempts
    grep "Failed password" /var/log/auth.log | awk '{print $1, $2, $11}' | sort | uniq -c | sort -rn
    
    # Find successful SSH logins
    grep "Accepted password" /var/log/auth.log | awk '{print $1, $2, $9, $11}'
    
    # Monitor logs in real-time
    tail -f /var/log/auth.log
    
    # Use journalctl (systemd systems)
    journalctl -u ssh.service --since "24 hours ago"
    journalctl _COMM=sshd --output=json
    

    Web Server Logs

    Apache/Nginx Common Log Format

    192.168.1.1 - - [01/Jun/2026:13:45:12 +0000] "GET /admin/login.php HTTP/1.1" 200 2345
    

    Fields: IP address, identity, user, timestamp, request, status code, bytes sent.

    Web Log Analysis

    # Find most requested URLs
    awk '{print $7}' /var/log/apache2/access.log | sort | uniq -c | sort -rn | head -20
    
    # Find 404 errors (potential scanning)
    awk '$9 == 404 {print $7}' /var/log/apache2/access.log | sort | uniq -c | sort -rn
    
    # Find SQL injection attempts
    grep -i "select|union|insert|--|'" /var/log/apache2/access.log
    
    # Analyze response time anomalies
    awk '{print $NF, $7}' /var/log/apache2/access.log | sort -rn | head -10
    
    # Find brute force attempts on login pages
    grep "POST /wp-login" /var/log/apache2/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -10
    

    DNS Log Analysis

    DNS logs provide visibility into the domains clients are resolving. DNS is often used for command and control (C2), data exfiltration, and tunneling.

    # Find top DNS queries
    grep "query:" /var/log/named.log | awk '{print $(NF-1)}' | sort | uniq -c | sort -rn | head -20
    
    # Find unusually long domain names (potential tunneling)
    awk 'length($NF) > 50 {print $NF}' /var/log/named.log | sort -u
    

    Suspicious DNS Patterns:

  • **DGA domains**: Random-looking subdomains (algorithmically generated)
  • **Tunneling**: Long subdomain names with encoded data
  • **Rare TLDs**: Uncommon top-level domains like .tk, .ml, .ga
  • **Fast flux**: Rapidly changing DNS records
  • **Known bad domains**: Matches against threat intelligence feeds
  • Cloud Service Logs

    AWS CloudTrail

    # Find IAM user creation
    aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=CreateUser
    
    # Find security group changes
    aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=AuthorizeSecurityGroupIngress
    
    # Query with jq
    aws cloudtrail lookup-events --query "Events[?EventName=='ConsoleLogin'].{Time:EventTime,User:Username,IP:SourceIPAddress}" --output json
    

    Azure Monitor

    # Sign-in logs
    SigninLogs
    | where TimeGenerated > ago(7d)
    | where ResultType != 0
    | summarize FailedAttempts = count() by UserPrincipalName, AppDisplayName
    | top 10 by FailedAttempts desc
    

    Correlation Techniques

    Time-Based Correlation

    Align events from multiple sources by timestamp to understand attack chains:

    14:01:01 — Firewall: Blocked connection from 1.2.3.4 to mail server
    14:01:02 — Web server: POST to /owa/auth/login.aspx from 1.2.3.4
    14:01:05 — Windows: Failed logon for admin@corp.local from 1.2.3.4
    14:01:10 — Windows: Successful logon for admin@corp.local from 1.2.3.4
    14:01:15 — EDR: PowerShell execution on mail server
    → Pattern suggests successful brute force attack on OWA
    

    Session-Based Correlation

    Group events by session ID or connection tuple (src_ip:port → dst_ip:port).

    Real-World Example: Investigating an Incident with Logs

    Scenario: Investigating a suspected data exfiltration.

  • **Alert**: DLP system alerts on large outbound data transfer from finance server
  • **Network Logs**: Firewall shows 2GB outbound traffic from finance server to 45.33.32.156 (unusual)
  • **DNS Logs**: Server queried "upload-data.tk" before the transfer
  • **Process Logs**: Event ID 4688 shows powershell.exe started from Excel (potential phishing)
  • **Authentication Logs**: User "jane.doe" had failed logins from IP 10.0.0.50 (compromised workstation)
  • **Timeline**: Phishing at 9 AM → credential theft → lateral movement → data exfiltration at 2 PM
  • **Evidence**: Complete timeline established from log correlation
  • Common Mistakes

  • **Not collecting sufficient logs** — Retention policies that are too short
  • **Ignoring time synchronization** — Logs without synchronized clocks cannot be correlated
  • **Over-centralizing** — Sending everything to SIEM without local storage (loses context)
  • **Focusing only on alerts** — Misses intelligence from non-alerting events
  • **No baseline understanding** — Cannot detect anomalies without knowing normal
  • Best Practices

  • **Enable comprehensive logging** — All security-relevant events, all systems
  • **Synchronize clocks** — NTP across all devices for accurate correlation
  • **Retain logs according to compliance** — Meet regulatory requirements
  • **Use structured logging** — JSON logs are easier to parse and analyze
  • **Automate analysis** — Use scripting and SIEM queries for routine analysis
  • **Build baselines** — Understand normal patterns before hunting for anomalies
  • **Protect log integrity** — Forward logs to immutable storage to prevent tampering
  • Related Tools

  • **Splunk** — Enterprise log analysis and SIEM
  • **ELK Stack** — Open-source log management
  • **Windows Event Viewer** — Native Windows log viewer
  • **journalctl** — systemd log viewer
  • **lnav** — Advanced log file navigator
  • **grep/awk/sed** — Command-line log analysis
  • Related Articles

  • SIEM Fundamentals: Security Information and Event Management
  • Security Monitoring: Building Detection Capabilities
  • Threat Hunting: Proactive Cyber Defense Strategies
  • Incident Response: Structured Approach to Security Breaches
  • Detection Engineering: Creating Security Alerts and Rules
  • Summary

    Log analysis is the foundation of security operations. Windows Event Logs, Linux Syslog, web server logs, DNS logs, and cloud logs each provide unique visibility. Effective analysis requires understanding key event IDs, log formats, correlation techniques, and using the right tools (grep, awk, PowerShell, SIEM). Time synchronization, comprehensive collection, and baseline understanding are critical for effective log analysis.

    Knowledge Check

  • What are the most important Windows Security Event IDs for security analysis?
  • What information is contained in a standard Apache combined log format entry?
  • Why is time synchronization critical for log analysis?
  • What suspicious DNS patterns indicate potential malicious activity?
  • How does session-based correlation differ from time-based correlation?
  • Frequently Asked Questions

    What are the most important Windows Security Event IDs for log analysis?

    Key Windows event IDs include 4624 (successful logon), 4625 (failed logon), 4688 (process creation), 4672 (special privileges), 4720 (account created), 4732 (user added to group), and 4104 (PowerShell script block). These events provide visibility into authentication, execution, and privilege changes.

    Why is time synchronization critical for log analysis?

    Time synchronization via NTP ensures events from different systems can be accurately correlated in timelines. Without synchronized clocks, events from firewalls, servers, and endpoints cannot be ordered correctly, breaking attack chain reconstruction and incident investigation.

    What suspicious DNS patterns indicate malicious activity?

    Suspicious DNS patterns include DGA (algorithmically generated) domains, unusually long subdomain names (potential tunneling), rare TLDs like .tk or .ml, fast-flux DNS with rapidly changing records, and queries to domains matching threat intelligence feeds.

    What information is in a standard Apache combined log format entry?

    A combined log format entry contains: client IP address, identity, authenticated user, timestamp, request method/URL/protocol, HTTP status code, bytes sent, referrer URL, and user-agent string. This provides a complete picture of each HTTP request.

    How do you detect SQL injection attempts in web logs?

    Search web access logs for suspicious patterns like 'UNION SELECT', 'OR 1=1', 'DROP TABLE', single quotes, double dashes, and encoded payloads in URL parameters. Combine with HTTP 500 errors to identify successful injection attempts.

    What are the key Linux log files for security analysis?

    Critical Linux logs include /var/log/auth.log (authentication events), /var/log/syslog (system messages), /var/log/kern.log (kernel events), /var/log/apache2/ (web server logs), and /var/log/nginx/ (Nginx logs). Use journalctl on systemd systems for structured querying.

    What is the difference between time-based and session-based log correlation?

    Time-based correlation aligns events from multiple sources by timestamp to reconstruct attack chains. Session-based correlation groups events by connection tuple or session ID. Time-based reveals attack sequences; session-based tracks individual communication sessions.

    How do you analyze cloud service logs for security threats?

    For AWS CloudTrail, monitor IAM user creation, security group changes, and console logins. For Azure Monitor, track failed sign-ins and privilege escalations. Use jq or KQL queries to filter events and detect anomalies in API call patterns and access behavior.

    What is log normalization and why does it matter?

    Log normalization converts different log formats (Windows Event Logs, Syslog, web logs) into a common schema for unified analysis. Without normalization, a SIEM cannot correlate events from different sources, creating blind spots in detection capabilities.

    What tools are commonly used for log analysis?

    Common log analysis tools include Splunk and ELK Stack for enterprise SIEM, grep/awk/sed for command-line analysis, PowerShell for Windows events, journalctl for systemd logs, and lnav for advanced log file navigation. The choice depends on scale and infrastructure.