When Logs Told the Story Before the Alerts Did
In early 2026, a mid-sized industrial manufacturer discovered that a threat actor had been moving laterally through their OT-adjacent network for eleven days before any alert fired. The investigation revealed something that security teams encounter repeatedly: the evidence was in the logs the entire time. Authentication logs showed repeated failed attempts from an internal service account at 2:47 AM. DNS query logs captured a domain that resolved to a known command-and-control infrastructure. Firewall logs recorded outbound connections to an Eastern European ASN on port 4444 every six minutes like clockwork. No single log source told the full story, but correlated together, they painted a clear picture of a compromise that had already completed its first phase.
This scenario reflects a broader pattern documented in Kaspersky's threat landscape report for industrial automation systems in Q4 2025, which highlighted a surge in targeted intrusions where attackers relied on living-off-the-land techniques specifically because they produce log noise that blends into normal operational activity. The lesson is consistent across incident reports: logs contain the signal. The challenge is building the analytical discipline to extract it before the damage compounds.
The Anatomy of a Log-Based Attack Chain
Threat actors rarely trigger a single, obvious event. Modern intrusion campaigns, including those attributed to groups like Lazarus and the infrastructure clusters associated with Scattered Spider, leave traces across multiple log sources that individually appear benign. Understanding how attacks unfold across log telemetry is the foundation of effective detection.
Consider a credential-based intrusion. The sequence typically begins with authentication log entries showing successful logins from an IP address that has never been seen in the environment, or from a geolocation inconsistent with the user's normal pattern. This is followed by access logs on file servers showing broad enumeration, where the account queries directory structures rather than accessing specific known files. Process execution logs then capture tools like net.exe, wmic.exe, or nltest.exe being run under that user context. Finally, network flow logs capture a connection to an external host that resolves to a domain registered within the past 30 days.
Each log entry in this chain has an innocent explanation in isolation. A user connecting from a new location is routine. Running net.exe is routine. Querying a recently registered domain could be a SaaS product. The attack only becomes visible when these events are correlated across a time window and mapped against baselines.
Log Sources That Matter Most and How to Actually Use Them
Authentication and Identity Logs
Windows Security Event logs, specifically Event IDs 4624, 4625, 4648, 4672, and 4768, form the backbone of identity-based detection. Event 4625 (failed logon) is widely monitored, but defenders often overlook the combination of 4624 (successful logon) with logon type 3 (network logon) from service accounts during off-hours. This combination, particularly when the source IP is a workstation rather than a server, indicates pass-the-hash or stolen token usage.
For environments running Active Directory, Kerberos ticket logs provide a layer that NTLM-focused monitoring misses. Ticket requests for sensitive SPNs from accounts that have no business accessing those services represent a Kerberoasting indicator that authentication failure logs alone would never surface. The Russia-linked campaign that harvested Microsoft Office tokens through compromised routers highlights exactly this gap: the token theft happened outside the perimeter, so internal authentication logs initially showed legitimate-looking successful logins.
DNS Query Logs
DNS is among the most underutilized log sources in enterprise environments. Every piece of malware, every C2 framework, and most data exfiltration techniques rely on DNS at some point. Logging DNS queries at the resolver level provides visibility into communications that firewall logs alone miss because DNS over port 53 is almost universally allowed outbound.
Patterns worth flagging in DNS logs include high-frequency queries to a single domain (beaconing behavior), queries for domains with high entropy names (algorithmically generated domains from DGA-based malware), queries for domains using non-standard TLDs that are common in phishing infrastructure, and queries to external resolvers like 8.8.8.8 from workstations that should be using internal DNS. The P2P botnet activity documented through continuous monitoring efforts in 2026 relies on DNS-based peer discovery mechanisms that leave consistent query patterns in resolver logs, even when the actual C2 traffic is encrypted.
Web and Proxy Logs
HTTP proxy or web gateway logs capture user-agent strings, referrer headers, URI paths, and response codes that SIEM rules often parse too shallowly. A user-agent string of python-requests/2.28.1 appearing on a workstation that runs Windows and should be generating browser user-agents is an immediate anomaly. Response code sequences matter equally: a 200 followed by repeated 404s from the same source IP across different URI paths indicates scanning behavior originating from inside the network, which means a compromised internal host is probing other services.
The TeamPCP group's attacks against SAP systems in early 2026 used web-layer techniques that left distinct URI pattern signatures in proxy logs. Post-exploitation traffic frequently included encoded payloads in GET parameters that standard WAF rules missed but were visible to analysts reviewing raw proxy logs with awareness of SAP's URL structure conventions.
Endpoint and Process Execution Logs
Windows Event ID 4688 (process creation with command-line logging enabled) and Sysmon Event ID 1 are indispensable for detecting post-exploitation activity. Command-line logging must be explicitly enabled in Windows audit policy; it is off by default. Once enabled, logs capture the full argument string passed to executables, which reveals encoded PowerShell, LOLBin abuse, and lateral movement tools.
Sysmon provides considerably richer telemetry, including parent-child process relationships (Event ID 1), network connections from processes (Event ID 3), and image load events (Event ID 7) that detect reflective DLL injection. The modified CIA Hive implant variants circulating in criminal ecosystems in 2025 and 2026 rely on process injection techniques that only become visible in logs when parent-child process anomalies are captured. A svchost.exe spawning cmd.exe is an immediate red flag; without process relationship logging, defenders see the child process but not the anomalous parentage.
Correlation: Turning Raw Events Into Actionable Detections
Individual log events have limited detection value. Correlation across sources and time windows is where log analysis becomes threat detection. The following correlation patterns have high fidelity in real-world environments.
Temporal Correlation: The Beacon Pattern
Beaconing malware communicates with C2 infrastructure at regular intervals. In firewall or proxy logs, this produces a recognizable pattern: connections to the same destination IP or domain at consistent intervals, often with jitter of plus or minus a few seconds to evade simple interval matching. Detecting beacons requires calculating the standard deviation of connection intervals for each source-destination pair over a sliding time window, typically four to six hours. A low standard deviation combined with an unusual destination (new IP, rare country, newly registered domain) is a high-confidence beacon indicator.
Many SIEM platforms support this calculation natively through statistical functions. In Splunk, the streamstats command calculates per-pair interval statistics. In Elastic, a combination of date histogram aggregations and pipeline aggregations achieves the same result. The implementation investment is justified by detection coverage across entire malware families, since the beaconing behavior is infrastructure-agnostic.
Cross-Source Correlation: Account Followed by Network
A powerful detection pattern links authentication events to network connection events for the same account or host within a short window. The sequence is: a service account authenticates successfully to a host it has not accessed in 30 days, and within 15 minutes, that host initiates an outbound connection to an external IP. Neither event alone is alarming. Together, they describe credential abuse followed by C2 establishment.
Implementing this requires joining authentication logs with network flow logs on the source hostname field. In environments where usernames do not appear in network logs, the join key is the source IP. The time window for the join should be configurable, starting at 30 minutes and tuning based on false positive rates in the specific environment.
Volume Anomalies: Data Staging and Exfiltration
Exfiltration leaves volume anomalies in network flow logs. A host that normally transfers 50 MB per day outbound and transfers 4 GB in a two-hour window at 11 PM has a detectable behavioral deviation. Establishing per-host baselines for outbound byte counts over rolling 30-day periods enables threshold-based alerting for volume anomalies.
FakeWallet crypto stealer activity analyzed in 2026 exfiltrated wallet credentials and session tokens through HTTPS connections to cloud storage endpoints. The behavioral signature in network logs was not the destination (cloud storage is expected) but the volume from mobile device management logs showing iOS devices generating abnormally large outbound transfers to non-corporate cloud providers.
Building Detection Rules That Stay Useful Over Time
Detection rules degrade. Attackers adapt, environments change, and rules written for last year's threat landscape generate noise against today's. Maintaining effective log-based detection requires treating rules as living artifacts with ownership and lifecycle management.
Each detection rule should document the threat behavior it targets (not just a CVE or malware name), the specific log sources and fields it depends on, the baseline data required for it to function accurately, a known false positive list derived from tuning exercises, and the last date it was reviewed against current threat intelligence.
For environments monitoring industrial systems or OT-adjacent networks, the threat landscape report data from Q4 2025 underscores the need for rules tailored to the specific process historian, SCADA, and DCS software in use. Generic Windows event rules miss the protocol-specific patterns that appear in OT environments. Custom rules built from vendor-specific log documentation dramatically improve signal quality for these systems.
Log Collection Architecture for Detection Coverage
Detection quality is bounded by collection quality. Gaps in log collection are gaps in detection coverage, and adversaries actively probe for these gaps. A collection architecture built for threat detection has several characteristics that distinguish it from one built primarily for compliance.
Forwarding logs to a central repository should happen over an encrypted, authenticated channel. Syslog over UDP to a collector that anyone on the network can spoof undermines the evidentiary value of the logs and creates an attack surface for log injection. TLS-wrapped syslog or agent-based collection with certificate authentication addresses both concerns.
Retention periods must align with dwell time realities. The average intrusion dwell time in enterprise environments still exceeds 20 days in many sectors. Retaining hot (searchable) logs for only seven days means that by the time a compromise is detected, the initial access logs have been purged. Ninety days of hot retention for endpoint and authentication logs, with a full year in cold storage, provides adequate forensic reach for most investigation scenarios.
Log integrity matters for both forensics and regulatory requirements. Write-once storage for log archives, combined with hash chaining or WORM storage policies, prevents log tampering by attackers who have achieved administrative access. The value of log data as forensic evidence depends entirely on its demonstrable integrity.
Practical Triage Workflow When an Alert Fires
The moment a log-based alert fires, defenders face a triage decision under time pressure. A structured workflow reduces the time from alert to action without sacrificing analytical quality.
- Scope the source. Pull the last 24 hours of all log types for the alerting host. Look for the earliest anomalous event, not just the triggering event. The alert may represent a later stage of an intrusion that started hours earlier.
- Check lateral movement indicators. Query authentication logs for successful logons from the alerting host to other systems in the same time window. If the host has authenticated to three or more other systems it does not normally contact, lateral movement is likely underway.
- Correlate the destination. If the alert involves outbound network activity, run the destination IP or domain through threat intelligence sources and check its first-seen date in your environment's DNS logs. A destination appearing for the first time simultaneously with other anomalies is a strong indicator of new C2 infrastructure.
- Assess the account. Determine whether the activity is associated with a user account or a service account. Service accounts generating interactive logons or running processes beyond their documented function represent a higher-confidence compromise indicator than user account anomalies, which have more legitimate explanations.
- Make the containment decision. Based on the above, decide whether to isolate the host immediately or continue monitoring. If lateral movement is confirmed, isolation becomes urgent because continued monitoring allows the attacker to complete their objective while defenders gather evidence.
Common Collection and Analysis Gaps to Close Now
Several log collection and analysis gaps appear repeatedly in post-incident reviews. Addressing these before an incident substantially improves detection outcomes.
- Command-line argument logging disabled on Windows. Enable process creation auditing with command-line logging via Group Policy under Advanced Audit Policy Configuration. Without this, Event 4688 records process names but not the arguments that reveal malicious intent.
- DNS logging not deployed at the resolver. Most organizations rely on firewall logs for DNS visibility, which captures IP-level connections to resolver addresses but not the actual query content. Enabling DNS debug logging on Windows DNS servers or deploying dedicated DNS logging infrastructure closes this gap.
- No baseline for service account behavior. Service accounts frequently become attacker targets because they have broad permissions and their activity generates less scrutiny. Building behavioral baselines for each service account, specifically which systems they authenticate to and at what times, enables anomaly detection that generic rules miss.
- Incomplete log forwarding from cloud workloads. Cloud-native resources generate audit logs (AWS CloudTrail, Azure Monitor, GCP Cloud Audit Logs) that are not automatically forwarded to on-premises SIEM platforms. Gaps in cloud log collection leave entire attack surfaces unmonitored.
- No alerting on log source failures. If a log source stops forwarding, the SIEM generates no alerts because it receives no events. Monitoring for expected log source heartbeats and alerting on silence is a basic but frequently absent control that attackers exploit by disabling logging agents before executing their primary objective.
Operationalizing Log Analysis as a Daily Practice
Log analysis for threat detection delivers consistent value when it is treated as an operational discipline rather than an incident-response afterthought. Security teams that review log summaries daily, maintain tuned detection rules, and conduct regular threat hunting exercises using log data find intrusions earlier and with less damage than teams that rely solely on automated alerting.
Structured log review during low-activity periods, such as reviewing the previous night's authentication and DNS query logs each morning, trains analysts to recognize normal patterns and spot deviations quickly. This baseline intuition is not replaceable by automation alone; it is the analytical context that makes automated alerts actionable rather than overwhelming.
The threat landscape in 2026 is defined by adversaries who understand enterprise detection tooling and design their operations to evade it. The consistent finding across intrusion investigations, from nation-state campaigns targeting OT infrastructure to criminal groups attacking financial platforms, is that evidence existed in logs before detection occurred. The gap is not in the data. The gap is in the analysis discipline, the collection architecture, and the correlation logic applied to the data that already exists.
