4.1 Log Fundamentals, Sources, and Host Logging

The Role of Logs in Security Operations

In modern Security Operations Centers (SOCs), logs are recorded representations of selected activity across endpoints, networks, cloud workloads, and applications. They are indispensable, but they are not infallible ground truth: a source can be disabled, filtered, delayed, overwritten, forged, or collected with the wrong time settings. Analysts therefore validate coverage, timestamps, integrity, and corroboration before drawing a conclusion.

Logs serve three primary operational functions in a SOC:

1. Real-Time Detection & Alerting: Security Information and Event Management (SIEM) systems ingest streaming event data to evaluate correlation rules and trigger immediate investigations upon detecting anomalous patterns (e.g., ten consecutive failed logons followed by a successful logon within thirty seconds).
2. Forensic Incident Reconstruction: When an intrusion is confirmed, incident response (IR) teams interrogate historical logs to determine initial access vectors, dwell time, lateral movement paths, and data exfiltration scope.
3. Compliance Evidence: Applicable contracts, laws, and standards can require particular audit controls, review frequencies, protections, and retention periods. PCI DSS, the HIPAA Security Rule, and Sarbanes-Oxley-related control programs differ; none should be summarized as one universal “continuous tamper-proof logging” mandate.

---

Enterprise Log Classification Taxonomy

To manage high-volume ingestion pipelines, SOC architectures categorize log data by functional origin:

---

Windows Host Event Logging Architecture

Microsoft Windows generates operational telemetry through the Windows Event Log subsystem, writing structured XML records to binary EVTX files located in %SystemRoot%\System32\Winevt\Logs\. The Windows Event Log service (eventlog.dll), hosted inside svchost.exe, manages log writes, channel routing, and access controls.

Windows organizes events into distinct Channels:

• Administrative Channels: High-value events intended for IT administrators and security analysts (e.g., System.evtx, Security.evtx).
• Operational Channels: Highly detailed runtime events capturing subsystem operational transitions (e.g., Microsoft-Windows-TaskScheduler/Operational.evtx, Microsoft-Windows-TerminalServices-LocalSessionManager/Operational.evtx).
• Analytic and Debug Channels: High-volume diagnostic events disabled by default due to storage overhead; written directly as event trace log (.etl) files.

Host security analysis relies heavily on the Security Log (Security.evtx) and the System Log (System.evtx).

Critical Windows Security Event IDs

1. Event ID 4624: Successful Account Logon

Event ID 4624 documents every successful authentication. Analyzing the Logon Type field is vital for distinguishing legitimate human actions from adversary automation, service persistence, and lateral movement:

2. Event ID 4625: An Account Failed to Log On

Indicates an authentication rejection. SOC analysts evaluate the Status and Sub Status hex codes to isolate specific attack types:

• 0xC000006A: Bad password entered with a valid username (common in brute-force and password-spraying attacks).
• 0xC000006D: Generic logon failure; the username or authentication information is incorrect. Use the sub-status and surrounding events to distinguish an unknown account from a bad password.
• 0xC0000064: The user account does not exist within the authenticating domain/system.
• 0xC0000072: The user account is currently disabled.
• 0xC0000234: Account locked out due to exceeding the configured account lockout threshold.
• 0xC000006E: Account logon time restriction violation.

3. Event ID 4672: Special Privileges Assigned to New Logon

Generated immediately after Event ID 4624 when an authenticated account possesses administrative or high-value rights. Sensitive privileges to monitor include:

• SeDebugPrivilege: Enables process memory inspection and debugging; required by credential-dumping tools to extract hashes from lsass.exe.
• SeTcbPrivilege: Act as part of the operating system; grants full operating system identity.
• SeImpersonatePrivilege / SeAssignPrimaryTokenPrivilege: Token impersonation and process creation under alternate security contexts (abused in Potato-style local privilege escalation exploits).
• SeBackupPrivilege / SeRestorePrivilege: Allows reading/writing any file on disk regardless of NTFS permissions (abused to steal NTDS.dit or SAM hives).

4. Event ID 4688: A New Process Has Been Created

Essential for process tree analysis. By default, Windows does not capture command-line strings. Administrators must enable Include command line in process creation events via Group Policy (Computer Configuration > Administrative Templates > System > Audit Process Creation). The resulting telemetry captures the Creator Process ID (parent), New Process ID (child), Process Name, CommandLine parameters (e.g., detecting obfuscated PowerShell commands with -enc), and Token Elevation Type.

5. Additional Key Windows Event IDs

• Event ID 4720: User Account Created (tracks rogue account provisioning).
• Event ID 4722: User Account Enabled (tracks reactivation of dormant administrative accounts).
• Event ID 4724: An attempt was made to reset an account's password.
• Event ID 4726: User Account Deleted.
• Event IDs 4728, 4732, 4756: Member added to Global, Local (e.g., local Administrators), or Universal security groups.
• Event ID 7045 (System Log): A new service was installed on the system (identifies persistence, PsExec service execution, and rootkits). Captures Service Name, Service File Name (ImagePath / binPath), and Service Type.
• Event ID 4697 (Security Log): A service was installed in the system (Security channel equivalent of 7045).
• Event ID 1102 (Security Log) / Event ID 104 (System Log): The audit log was cleared (strong indicator of anti-forensic activity; generated even if an attacker purges all other records).

---

Microsoft Sysmon (System Monitor)

While native Windows Security auditing captures basic events, Microsoft Sysmon (part of Sysinternals) provides deep, kernel-level behavioral telemetry. Sysmon installs as a kernel device driver (sysmon.sys) and a user-mode service (sysmon.exe), writing directly to Microsoft-Windows-Sysmon/Operational in EVTX format.

<!-- Sample Sysmon XML Configuration Filter -->
<Sysmon schemaversion="4.90">
  <HashAlgorithms>SHA256,IMPHASH</HashAlgorithms>
  <EventFiltering>
    <!-- Event ID 1: Process Creation - Include suspicious parent/child patterns -->
    <RuleGroup name="ProcessCreation" groupRelation="or">
      <ProcessCreate onmatch="include">
        <Image condition="end with">powershell.exe</Image>
        <Image condition="end with">cmd.exe</Image>
        <ParentImage condition="end with">w3wp.exe</ParentImage>
      </ProcessCreate>
    </RuleGroup>
    <!-- Event ID 10: ProcessAccess - Monitor attempts to open LSASS memory -->
    <RuleGroup name="LsassAccess" groupRelation="or">
      <ProcessAccess onmatch="include">
        <TargetImage condition="end with">lsass.exe</TargetImage>
        <GrantedAccess condition="is">0x1010</GrantedAccess>
      </ProcessAccess>
    </RuleGroup>
  </EventFiltering>
</Sysmon>

Key Sysmon Event IDs

• Event ID 1 (Process Creation): Logs full process launch details, parent process command lines, user context, and cryptographic image hashes (SHA256, MD5, IMPHASH).
• Event ID 3 (Network Connection): Maps outbound/inbound TCP/UDP connections directly to the originating Process ID, executable path, source/destination IP, and port numbers.
• Event ID 5 (Process Terminated): Logs when a process stops executing, capturing Process ID and executable image name.
• Event ID 7 (Image Loaded): Tracks module/DLL loading within processes. Critical for detecting DLL sideloading and DLL search order hijacking; records digital signature verification status.
• Event ID 8 (CreateRemoteThread): Detects process injection techniques where an adversary creates an execution thread inside a remote process (e.g., injecting shellcode into svchost.exe or explorer.exe).
• Event ID 10 (ProcessAccess): Records when one process opens a handle to another via OpenProcess. Monitors credential theft attempts against the Local Security Authority Subsystem Service (lsass.exe) with access masks such as 0x1010 (PROCESS_QUERY_LIMITED_INFORMATION | PROCESS_VM_READ) or 0x1F0FFF (PROCESS_ALL_ACCESS).
• Event ID 11 (FileCreate): Logs file system creation events, capturing ransomware ransom notes and dropped executable payloads.
• Event IDs 12, 13, 14 (Registry Events): Capture registry object creation/deletion (12), value modification (13), and renaming (14). Primary detection source for Run/RunOnce persistence keys and Image File Execution Options (IFEO) hijacking.
• Event ID 22 (DNSEvent): Records DNS queries initiated by individual processes, capturing the query name, query status, and returned IP results.

Windows Security Event IDs vs. Sysmon Event IDs

---

Linux and Unix Host Telemetry

Linux and Unix operating systems write human-readable and binary logs to /var/log. The logging subsystem is traditionally managed by rsyslog or systemd-journald.

Standard Linux Log Directory Structure

Systemd Journal Telemetry (journalctl)

Modern systemd-based Linux distributions capture centralized binary logs managed by systemd-journald stored in /run/log/journal/ (volatile) or /var/log/journal/ (persistent). SOC analysts query the journal using journalctl:

# Inspect all authentication events from the current boot session
journalctl -b _COMM=sshd

# Query events for a specific systemd unit with priority Warning or higher
journalctl -u nginx.service -p warning

# Stream logs in real time with timestamp precision
journalctl -f -o short-iso

Linux Audit Framework (auditd)

For enterprise environments requiring granular kernel-level tracking, the Linux Audit Framework (auditd) intercepts system calls directly through the kernel netlink socket. Audit rules are defined in /etc/audit/audit.rules (or /etc/audit/rules.d/) and loaded via auditctl.

# Sample auditd Rule Configuration (/etc/audit/rules.d/csa_audit.rules)

# 1. File Watch: Monitor modification of credential storage
-w /etc/shadow -p wa -k credential_tamper
-w /etc/passwd -p wa -k credential_tamper

# 2. File Watch: Monitor changes to administrative privileges
-w /etc/sudoers -p wa -k privilege_escalation
-w /etc/sudoers.d/ -p wa -k privilege_escalation

# 3. System Call Auditing: Capture all process execution (64-bit)
-a always,exit -F arch=b64 -S execve -k process_execution

Audit rules utilize three primary flags:

• -w <path>: Sets a file system watch on the designated target path.
• -p <permissions>: Specifies permission filters to trigger on: r (read), w (write), x (execute), and a (attribute change).
• -k <key_name>: Attaches a searchable identifier string to all matching events.
• -a always,exit: Configures a system call filter that evaluates when a system call terminates.

Querying Audit Telemetry: ausearch and aureport

SOC analysts query audit logs using dedicated command-line utilities:

# Search for events matching the custom key 'credential_tamper'
ausearch -k credential_tamper

# Search for failed user login events
ausearch -m USER_LOGIN -sv no

# Generate an authentication summary report across all users
aureport --auth

# Generate a summary report of all executable commands run on the host
aureport -x --summary

---

macOS Unified Logging and Host Artifacts

Modern macOS uses the unified logging system, which collects structured messages from the operating system and applications into an in-memory and on-disk log store. The log command queries or streams this store. Analysts should scope queries by time and use predicates for fields such as process, subsystem, category, event message, and message type rather than exporting an unbounded stream.

# Review the previous hour for authentication-related messages
log show --last 1h --style compact   --predicate 'process == "loginwindow" OR subsystem CONTAINS[c] "auth"'

# Stream new messages for a specific process during controlled testing
log stream --style compact --predicate 'process == "sshd"'

Useful macOS evidence also includes Apple System Log or application files that still write under /var/log, install history, quarantine metadata, launch agents and daemons, File System Events (FSEvents), shell history, and endpoint-security telemetry. Privacy controls can redact some message values, retention varies, and log erase or store rollover can remove local history. A robust collection design forwards security-relevant macOS telemetry to protected centralized storage and correlates it with identity, DNS, proxy, and EDR evidence.