13.4 SIEM Event Correlation, Cross-Source Timeline Analysis & Super-Timeline Construction

13.4 SIEM Event Correlation, Cross-Source Timeline Analysis & Super-Timeline Construction

Quick Answer: Modern incident response relies on centralized log ingestion and temporal reconstruction. SIEM platforms ingest event logs across endpoints, firewalls, and proxies via Syslog protocols (RFC 3164 / RFC 5424) and Windows Event Forwarding (WEF) over WinRM. Syslog Priority (PRI) values encode both Facility and Severity via the formula PRI = (Facility * 8) + Severity. Multi-source event correlation links isolated atomic events (e.g., VPN logon, internal port scan, privilege escalation, outbound data spike) into a cohesive attack story. In digital forensics, timeline reconstruction progresses from basic filesystem MACB analysis to comprehensive super-timelines using Plaso (log2timeline) and psort. To prevent catastrophic sequence misordering, investigators must calculate clock drift / time skew across all devices and normalize every timestamp strictly to Coordinated Universal Time (UTC).

---

Centralized Log Aggregation, Normalization & SIEM Architectures

Enterprise networks generate billions of raw log events daily across heterogeneous platforms. A Security Information and Event Management (SIEM) platform functions as the central nervous system for security monitoring and incident response.

+-------------------------------------------------------------------------+
|                         SIEM LOG PIPELINE TIERS                         |
+-------------------------------------------------------------------------+
| Tier 1: Log Collection   | Forwarders (Splunk UF, Elastic Agent, Rsyslog)|
|                          | transmit raw logs over TCP/TLS               |
| Tier 2: Normalization    | Ingestion pipeline parses unstructured text  |
|                          | into common schemas (ECS, CIM, OSSEM)        |
| Tier 3: Indexing/Storage | Optimized time-series indexing & hot/warm/   |
|                          | cold data tier storage architectures         |
| Tier 4: Correlation      | Real-time rule evaluation, thresholding,     |
|                          | and behavioral anomaly detection engines     |
| Tier 5: Presentation     | Dashboards, alert triage queues, and forensic|
|                          | hunt search interfaces                       |
+-------------------------------------------------------------------------+

Syslog Protocol Standards: RFC 3164 vs. RFC 5424

Syslog is the foundational protocol for forwarding system messages over IP networks.

+-------------------------------------------------------------------------+
|                    RFC 3164 vs. RFC 5424 SYSLOG STANDARDS               |
+-------------------------------------------------------------------------+
| Metric              | RFC 3164 (BSD Syslog)    | RFC 5424 (IETF Syslog)  |
|---------------------|--------------------------|-------------------------|
| **Transport**       | UDP Port 514 (Default)   | TCP/TLS Port 6514 / UDP |
| **Timestamp Res.**  | Second-level only        | Microsecond ISO 8601    |
|                     | (e.g., Sep 22 14:00:15)  | (2026-09-22T14:00:15.12Z)|
| **Timezone Offset** | None (Assumes local time)| Explicit UTC offset     |
| **Structure**       | Free-form text message   | Structured Data Elements|
|                     | after header             | ([exampleSDID@32473...])|
| **Header Format**   | <PRI>TIMESTAMP HOST TAG: | <PRI>VERSION TIMESTAMP  |
|                     | MSG                      | HOST APP PROC MSGID SD  |
+-------------------------------------------------------------------------+

The Syslog PRI Calculation Formula

Every syslog packet begins with a Priority value enclosed in angle brackets (e.g., <85>). This integer represents two distinct metrics: Facility (source program type, 0–23) and Severity (urgency level, 0–7).

$\text{PRI} = (\text{Facility} \times 8) + \text{Severity}$

Syslog Facility Codes:                     Syslog Severity Levels:
 0 = kernel messages                        0 = Emergency (System unusable)
 1 = user-level messages                    1 = Alert (Action must be taken)
 3 = system daemons                         2 = Critical (Critical conditions)
 4 = security/authorization                 3 = Error (Error conditions)
 10 = authpriv (Private auth)               4 = Warning (Warning conditions)
 16-23 = local0 through local7              5 = Notice (Normal but significant)
                                            6 = Informational
                                            7 = Debug

Forensic Calculation Example: If a syslog entry has <84>, what is its facility and severity?

• $\text{Facility} = \lfloor 84 / 8 \rfloor = 10$ (authpriv - secure authentication system)
• $\text{Severity} = 84 \pmod 8 = 4$ (Warning)

Windows Event Forwarding (WEF) & High-Value EVTX Telemetry

Windows endpoints forward native XML-structured Event Logs (*.evtx) to a centralized Windows Event Collector (WEC) using the WS-Management (WS-Man) protocol over WinRM (HTTP Port 5985 / HTTPS Port 5986).

+-------------------------------------------------------------------------+
|             HIGH-VALUE WINDOWS SECURITY EVENT IDS FOR SIEM              |
+-------------------------------------------------------------------------+
| Event ID | Log Provider       | Description & Forensic Significance      |
|----------|--------------------|------------------------------------------|
| **4624** | Microsoft-Security | Successful Logon (Check LogonType:       |
|          |                    | Type 2=Interactive, Type 3=Network/SMB,  |
|          |                    | Type 10=Remote Desktop RDP)              |
| **4625** | Microsoft-Security | Failed Logon Attempt (Brute force triage)|
| **4688** | Microsoft-Security | Process Creation (Includes CommandLine)  |
| **4697** | Microsoft-Security | A service was installed on the system    |
| **7045** | System             | New service installed (Persistence / PSS)||
| **4720** | Microsoft-Security | A user account was created               |
| **4738** | Microsoft-Security | A user account was modified              |
| **1102** | Microsoft-Security | The audit log was cleared (Anti-forensics|
| **1**    | Microsoft-Sysmon   | Process Creation (ParentImage, Hashes)   |
| **3**    | Microsoft-Sysmon   | Network Connection Initiated             |
| **8**    | Microsoft-Sysmon   | CreateRemoteThread (Process Injection)   |
| **13**   | Microsoft-Sysmon   | Registry Event (Value Set / Persistence) |
+-------------------------------------------------------------------------+

---

Multi-Source Event Correlation Techniques

Isolated log events provide weak evidential value in isolation. A failed logon (4625) occurs thousands of times daily in large enterprises. However, when correlated across time and disparate sources, atomic events transform into actionable incident graphs.

Cross-Source Incident Reconstruction Workflow:

 [External Firewall]        [Internal Active Directory]         [Endpoint Sysmon]
          │                              │                              │
  Inbound VPN Auth               Multiple Kerberos              Sysmon Event 1
  from Unrecognized IP           TGS Requests (SPN)             cmd.exe executes
  (2026-09-22 02:00:10Z)         (2026-09-22 02:04:15Z)         vssadmin.exe
          │                              │                      (2026-09-22 02:15:30Z)
          └──────────────┬───────────────┘                              │
                         ▼                                              ▼
                 [SIEM Correlation Engine] ─────────────────────────────┘
                         │
                         ▼
            High-Fidelity Incident Generated:
            "Compromised Credentials -> Kerberoasting -> Ransomware Staging"

Primary Correlation Methodologies

1. Rule-Based / Deterministic Correlation: Evaluates logs against rigid Boolean conditions and sequence constraints.
   • Example: Trigger Alert if EventID == 4625 occurs $\ge 5$ times within 60 seconds from $Source_IP, followed by EventID == 4624 from the same $Source_IP within 120 seconds (Brute Force Success).
2. Statistical Thresholding & Baseline Anomaly Correlation: Compares real-time metrics against historical statistical baselines (e.g., volume of outbound DNS queries, daily gigabytes transferred per user). If activity exceeds 3 standard deviations ($> 3\sigma$) from the 30-day moving average, an anomaly is flagged.
3. Cross-Source Pivot Keys: The technical glue that connects disparate logs into a unified thread:
   • User Account Names: Tracks an identity moving from VPN concentrator to Active Directory domain controller to internal workstation.
   • Source/Destination IP and Ephemeral Port Pairs: Correlates an outbound proxy request with an edge firewall state table and an endpoint socket.
   • Logon ID (TargetLogonId / 0x3E7): Uniquely identifies a specific user session across all Windows security events occurring during that logon lifetime.

---

Digital Forensics Timeline Analysis: MACB vs. Super-Timelines

Chronological sequence reconstruction is the single most powerful analytical technique in digital forensics. Establishing exactly who did what, when, and in what order directly proves intent and establishes attribution.

Understanding Filesystem MACB Timestamps

Filesystem metadata stores four primary temporal attributes, commonly referred to by the acronym MACB:

+-------------------------------------------------------------------------+
|                    MACB TIMESTAMP DEFINITIONS                           |
+-------------------------------------------------------------------------+
| Letter | Name       | NTFS Definition            | Ext4 (Linux) Definition|
|--------|------------|----------------------------|------------------------|
| **M**  | Modified   | File content last altered  | File content modified  |
| **A**  | Accessed   | File opened or read        | File read / accessed   |
| **C**  | Changed    | MFT record metadata changed| Inode metadata changed |
|        | (Metadata) | (Permissions, size, links) | (Chmod, chown, link)   |
| **B**  | Born       | File creation timestamp    | File creation (crtime) |
|        | (Created)  | ($STANDARD_INFORMATION)    | (Not stored in Ext2/3) |
+-------------------------------------------------------------------------+

The Shift from Filesystem Timelines to Super-Timelines

• Filesystem-Only Timeline (fls / mactime): Tools like The Sleuth Kit's fls extract MACB timestamps exclusively from file system allocation structures (e.g., the NTFS $MFT or FAT directory tables). This misses all non-filesystem activity.
• Super-Timeline: Synthesizes temporal artifacts from dozens of heterogeneous operating system sources into a single master chronology: filesystem MACB, Windows Registry hive key LastWrite times, event logs (*.evtx), browser history databases (SQLite), Prefetch execution artifacts, LNK shortcut files, Jumplists, scheduled task logs, and Unix shell history (.bash_history).

---

Super-Timeline Construction with Plaso / log2timeline

Plaso is the modern Python-based open-source framework designed to automate the extraction of super-timelines from raw forensic disk images, triage archives, or volume shadow copies.

+-------------------------------------------------------------------------+
|                 PLASO TOOLSET OPERATIONAL PIPELINE                      |
+-------------------------------------------------------------------------+
| Tool Name       | Operational Stage      | Function & Output Container  |
|-----------------|------------------------|------------------------------|
| **log2timeline**| Extraction Phase       | Scans storage image with     |
|                 |                        | multi-threaded parsers;      |
|                 |                        | writes to Plaso storage file |
|                 |                        | (*.plaso / SQLite / dynamic) |
| **psort**       | Filtering & Slicing    | Reads .plaso file; applies   |
|                 |                        | time slices and BPF-like     |
|                 |                        | filters; formats output      |
| **pinfo**       | Validation & Auditing  | Inspects .plaso file metadata|
|                 |                        | and parser execution stats   |
+-------------------------------------------------------------------------+

Practical Command-Line Execution

1. Extracting Artifacts with log2timeline.py

# Extract all timeline artifacts from an E01 forensic disk image into a plaso container
log2timeline.py --parsers "win7,win_evtx,ntfs,sqlite" --storage-file /cases/CASE-2026/evidence.plaso /evidence/disk_image.E01

2. Filtering and Exporting with psort.py

Once the extraction engine populates the .plaso database, investigators use psort.py to filter the data to a specific investigative window and output the results into a readable CSV or SIEM format:

# Export a micro-timeline spanning a 48-hour incident window in L2T CSV format
psort.py -z UTC -o l2tcsv -w /cases/CASE-2026/timeline_incident.csv \
  --slice "2026-09-20 00:00:00 to 2026-09-22 23:59:59" \
  /cases/CASE-2026/evidence.plaso

Dissecting L2T CSV Format Fields:

The standard Log2Timeline CSV format contains seventeen standardized fields:

• date: Date in MM/DD/YYYY format.
• time: Time in HH:MM:SS format.
• timezone: Timezone of output (forced to UTC via -z UTC).
• MACB: 4-character string displaying active timestamp types (e.g., M... for modified only, MACB for all four).
• source: High-level artifact category (e.g., LOG, REG, FILE, WEBHIST).
• sourcetype: Specific parser that recovered the event (e.g., WinEVTX, NTFS $MFT, Chrome History).
• type: Specific timestamp description (e.g., Last Written, Content Modification, File Created).
• user: Associated Windows or Linux user identity.
• host: Hostname of the target endpoint.
• desc: Detailed descriptive event string (e.g., executable command line, registry key value, URL visited).

---

Time Skew, Hardware Clock Drift & Multi-Timezone Normalization

In complex multi-host investigations (e.g., an attacker pivoting from an offshore jump box to a cloud proxy, then through an on-premises firewall to an internal domain controller), chronological misordering is the primary cause of flawed investigative conclusions.

+-------------------------------------------------------------------------+
|                    SOURCES OF TIMESTAMP INCONSISTENCY                   |
+-------------------------------------------------------------------------+
| Source Type         | Technical Mechanism       | Forensic Impact       |
|---------------------|---------------------------|-----------------------|
| **Clock Drift**     | Hardware RTC quartz       | Internal clocks gain  |
|                     | oscillator drift          | or lose seconds daily |
| **Unsynchronized**  | Network time protocol     | Log sources offset by |
| **NTP Sensors**     | disabled or misconfigured | minutes or hours      |
| **Timezone Shifts** | Local daylight saving time| 1-hour temporal gaps  |
|                     | (DST) or regional offsets | or duplicated hours   |
| **Anti-Forensic**   | Deliberate clock altering | Disorganizes security |
| **Timestomping**    | by adversary prior to log | events; hides payload |
+-------------------------------------------------------------------------+

The Mathematical Normalization Process

To synchronize logs across multiple systems, the forensic investigator must establish a Delta Offset ($\Delta t$) for each system relative to an authoritative reference clock (such as a GPS-synchronized enterprise NTP stratum server):

$\text{Timestamp}_{\text{Normalized (UTC)}} = \text{Timestamp}_{\text{Local}} - \text{Timezone Offset} \pm \Delta t_{\text{Drift}}$

Practical Skew Correction Protocol:

1. Record Live Clock Discrepancies: Immediately upon seizing or triaging a live machine, compare the system clock against an authoritative NTP time source: w32tm /stripchart /computer:time.windows.com /samples:5 /dataonly.
2. Examine NTP Sync Logs: In Windows Event Viewer, inspect Microsoft-Windows-Time-Service/Operational (Event ID 261 indicates time synchronization changes).
3. Universal UTC Normalization: Never maintain local timezone timestamps (e.g., EDT, CEST) in investigative notes or super-timelines. Standardize all cross-source artifacts to UTC.

---

Event Correlation: Prerequisites, Approaches and Deconfliction

Building a super-timeline is mechanical; correlating the events on it is the analytical step the blueprint tests separately.

Prerequisites of Event Correlation

Correlation produces nonsense unless four preconditions hold:

1. Time synchronization — every source disciplined to the same authoritative reference, with any skew measured and documented (the protocol above).
2. Normalization — heterogeneous records reduced to a common schema of who, what, where, when, and outcome.
3. Sufficient log coverage and retention — a source that was never enabled, or that rotated away, cannot be correlated.
4. A defined entity model — a consistent way to resolve a user, a host, and an IP address across sources, which is what the DHCP and VPN pivots in Section 13.6 supply.

Types of Event Correlation

Event Deconfliction

Deconfliction is the discipline of ensuring that two agencies, teams, or sensors working the same activity do not mistake one another's actions for adversary activity, and do not compromise one another's operations.

• Operational deconfliction: a red team exercise, a sanctioned penetration test, or a partner agency's covert operation can generate exactly the telemetry an investigator would attribute to an intruder. Before declaring an incident, confirm against the authorized-testing register.
• Data deconfliction: the same physical event frequently appears in several sources — a firewall record, a NetFlow record, and an IDS alert for one connection. Counting them as three events inflates the apparent scale of an attack. Collapse duplicates onto the single underlying transaction.
• Case deconfliction: national systems exist so that two agencies investigating the same target or infrastructure discover one another rather than colliding.

[!WARNING] Failing to deconflict produces two characteristic errors: attributing an authorized red-team action to a real adversary and burning investigative hours on it, or the reverse — dismissing genuine intrusion activity as "probably the pen test." Both are avoided by checking the register and recording that the check was performed.

Timeline and Kill Chain Analysis

Mapping correlated events onto the intrusion kill chain converts a flat timeline into a narrative that exposes gaps:

The practical value is diagnostic: if the timeline shows installation and C2 but no delivery, the delivery evidence exists somewhere that has not yet been collected. A missing phase is a collection gap, not proof the phase did not occur. MITRE ATT&CK provides the finer-grained technique mapping that most SIEM correlation content is now written against.