The Uncomfortable Truth About Log Data
Most organizations collect logs religiously. Firewalls, web servers, authentication systems, DNS resolvers, endpoint agents — all of them generate a continuous stream of structured and semi-structured data that gets shipped to a central store, compressed, indexed, and largely ignored until something goes wrong. The assumption that logging equals detection is one of the most persistent and costly misconceptions in operational security.
Log analysis for threat detection is not a storage problem. It is an interpretation problem. The data is there. The gap is in knowing which signals indicate an active threat, which represent normal noise, and what sequence of events constitutes a meaningful attack pattern rather than coincidence. This article is built around that gap, with practical guidance for security teams who want to turn their log infrastructure into a genuine detection capability rather than a compliance checkbox.
What Attackers Actually Leave Behind
Understanding what to look for starts with understanding attacker behavior at a log level. Modern intrusion campaigns are rarely noisy. The tradecraft documented in recent DFIR reporting on SystemBC, a proxy malware tool favored by ransomware affiliates, illustrates this clearly. SystemBC creates SOCKS5 proxy tunnels that blend into outbound HTTPS traffic. From a raw log perspective, the connection looks unremarkable: a standard TLS handshake, a destination IP on a cloud provider or residential network, a duration that falls within normal session ranges. The only way to identify it is through behavioral correlation across multiple log sources rather than per-event signature matching.
This pattern appears consistently across current threat categories. Ransomware groups use legitimate remote management tools during their dwell time, generating Windows event logs that look identical to normal administrative activity. Phishing campaigns now route through services like Amazon SES, meaning email header logs show a trusted sending infrastructure rather than an obviously malicious source. FakeWallet applications distributed through iOS app stores communicate with command-and-control infrastructure over standard HTTPS, producing access logs that resemble normal API traffic. The signal exists in each case, but it requires context, correlation, and a clear hypothesis about what an attack looks like at the data layer.
Building a Log Collection Architecture That Actually Supports Detection
Before any detection logic can work, the log collection pipeline itself must be sound. Many teams discover gaps in their coverage only after an incident. Common collection failures include endpoints that buffer logs locally and drop them on reboot, network devices configured to log only connection establishment rather than teardown, and cloud workloads that generate logs into a separate tenant that the security team cannot access.
A practical collection architecture for threat detection prioritizes the following source categories:
- Authentication logs: Active Directory security events (particularly 4624, 4625, 4648, 4768, 4769, 4776), RADIUS, LDAP, and SSO provider audit trails. These cover both initial access and lateral movement phases.
- DNS query logs: Full recursive resolver logs, not just denied queries. DNS is used for command-and-control, data exfiltration, and reconnaissance. Resolvers that only log failures miss the majority of malicious activity.
- Network flow records: NetFlow or IPFIX data from core switching and internet edge devices. These provide connection-level visibility without the storage overhead of full packet capture.
- Web and application access logs: Including all HTTP status codes, user-agent strings, referrer headers, and response sizes. Truncated logs that omit response bodies or headers reduce detection fidelity significantly.
- Endpoint process creation logs: Windows event ID 4688 with command line auditing enabled, or Sysmon event ID 1. These reveal execution chains that authentication logs alone cannot show.
- Cloud API audit trails: AWS CloudTrail, Azure Activity Log, GCP Cloud Audit Logs. API calls represent the primary attack surface in cloud environments and must be treated with the same priority as on-premises authentication events.
Retention periods matter for detection as well as compliance. Attackers with long dwell times, which remain common in ransomware precursor activity, often establish persistence weeks before triggering their final payload. A 30-day retention window means evidence of initial access may be gone before the investigation begins. Organizations handling sensitive data should target 90 days of hot storage for security-relevant log sources and 12 months of cold storage for forensic reconstruction.
Parsing and Normalization Before Analysis
Raw log data is structurally inconsistent. A Palo Alto firewall log, a Linux syslog entry, and an AWS CloudTrail record all describe network activity in fundamentally different formats. Analysis at scale requires normalization to a common schema before any detection logic runs. This is where many SIEM deployments fail in practice: organizations deploy a platform, configure log ingestion, and begin writing detection rules against raw log fields that vary between device versions or firmware updates.
The Elastic Common Schema (ECS) and the Open Cybersecurity Schema Framework (OCSF) both provide vendor-neutral field mappings designed for this purpose. Adopting one as an internal standard and enforcing it at the log pipeline layer, before data lands in the SIEM, produces more reliable detection rules and reduces maintenance overhead when log source configurations change.
Timestamp normalization deserves specific attention. Events from systems in different time zones, or with clock drift, produce correlation failures that look like detection gaps. All log sources should emit timestamps in UTC, and the collection pipeline should validate and correct timezone data before indexing. A lateral movement sequence that spans a domain controller in London and a workstation in Singapore will only correlate correctly if both timestamps reference the same epoch.
Detection Strategies That Go Beyond Signatures
Signature-based detection, matching log entries against known-bad patterns, remains useful but insufficient. Adversaries adapt to known signatures. The more productive approach layers multiple detection strategies, each covering different aspects of attacker behavior.
Baseline Deviation
Establish normal behavior profiles for users, systems, and network flows, then alert on statistically significant deviations. A service account that authenticates to five systems per day and suddenly authenticates to 200 systems in a three-hour window is anomalous regardless of whether any individual authentication event matches a known-bad pattern. Building these baselines requires 30 to 60 days of clean historical data and a mechanism for updating them as legitimate behavior patterns evolve.
Useful baseline metrics include: authentication volume per account per hour, outbound connection count per endpoint per day, DNS query rate per internal resolver client, and data transfer volume per cloud storage bucket per week. Deviations exceeding two to three standard deviations from the rolling mean warrant automated triage.
Sequence-Based Detection
Many attacks follow predictable sequences that are only visible when log events are correlated across time. A common ransomware precursor chain in current incident data follows this pattern: a phishing link click generates a web proxy log entry, followed within minutes by a PowerShell download cradle visible in endpoint process logs, followed by a new scheduled task creation in Windows event logs, followed by outbound connections to a new external IP in flow records.
No single event in that chain is definitively malicious. Correlated as a sequence within a defined time window, they represent a high-confidence intrusion indicator. SIEM platforms that support event sequencing or correlation rules can encode this logic directly. Splunk's transaction command, Elastic's EQL sequences, and Microsoft Sentinel's entity behavior analytics all provide mechanisms for sequence-based detection.
The SystemBC activity documented in recent threat research follows a similar multi-stage pattern. Initial access via a commodity loader, followed by SystemBC installation for persistent proxy capability, followed by hands-on-keyboard activity using the proxy tunnel. Each stage is visible in logs if the right sources are collected and the correlation logic is in place.
Threat Intelligence Integration
External threat intelligence, including IP reputation data, domain blocklists, file hashes, and certificate indicators, adds a layer of context that internal baselines cannot provide. The practical challenge is integrating intelligence feeds at a scale that does not create excessive false positives or processing overhead.
Effective integration focuses on enrichment rather than blocking. When a log entry contains an external IP address, the analysis pipeline should automatically query reputation data and attach the result as metadata. Analysts reviewing the event then see not just the raw connection but also whether the destination IP is associated with known malicious infrastructure, hosting ASNs commonly used for bulletproof hosting, or geographic origins inconsistent with the organization's expected traffic profile.
P2P botnet infrastructure, which current monitoring efforts track extensively, is particularly relevant here. Botnet nodes cycle through IP addresses rapidly, meaning static blocklists have limited utility. Dynamic enrichment against continuously updated feeds provides far better coverage. The same applies to residential proxy networks used by attackers to blend malicious traffic with legitimate consumer IP ranges, a technique that makes source-based blocking unreliable and reinforces the need for behavioral analysis alongside IP reputation signals.
Privileged Account Monitoring
Privileged account abuse is a consistent element of advanced intrusion campaigns. Monitoring for specific Windows event IDs provides structured visibility into credential-related activity that generic authentication logs miss. Event ID 4672 logs special privilege assignment at logon. Event ID 4698 logs scheduled task creation. Event ID 7045 logs new service installation. Event ID 1102 logs security log clearance, which represents an attacker attempting to destroy evidence.
When a privileged account generates event 4672 from a workstation rather than a server, followed by event 4698 within ten minutes, the sequence warrants immediate investigation. Building detection rules around these privilege-sensitive event IDs, rather than attempting to monitor all authentication activity equally, reduces alert volume while maintaining coverage for high-risk behaviors.
Cloud Log Analysis: Where Most Teams Have Blind Spots
Cloud infrastructure introduces log sources that many security teams have less operational familiarity with compared to traditional on-premises systems. API audit logs in cloud environments are functionally equivalent to combined authentication and process execution logs, because every infrastructure change is an API call. Reading them effectively requires understanding what normal API usage looks like for each service.
In AWS, high-risk API calls that should generate immediate alerts include: CreateUser, AttachUserPolicy, CreateAccessKey, and PutBucketPolicy when called outside normal administrative workflows. In Azure, Add member to role, Create or update role assignment, and modifications to conditional access policies represent equivalent high-risk events. These calls appear in the audit trail with full context including the calling identity, source IP, and timestamps, making them straightforward to alert on once the detection logic is in place.
Storage access logs deserve specific attention given current data exfiltration trends. An S3 bucket that receives 10,000 GetObject requests in a single hour from a single external IP, or a previously inactive storage account that suddenly transfers several gigabytes outbound, represents a high-priority anomaly. Cloud providers generate these access logs by default in some cases and require explicit configuration in others. Security teams should audit their cloud log enablement as a foundational step, because detection rules against logs that are not being collected produce no alerts by design.
Operationalizing Log Analysis: From Data to Decision
Detection logic produces alerts. Alerts require a response workflow that determines whether an event represents a genuine threat, a false positive, or an indicator requiring further investigation. The gap between detection and response is where log analysis investments most commonly fail to deliver operational value.
A triage workflow for log-derived alerts should answer four questions in sequence:
- Is this event technically valid? Check whether the log data is well-formed, the timestamp is accurate, and the source is a legitimate asset in inventory. Malformed or out-of-sequence events often indicate log collection issues rather than security events.
- Does this event have known-benign explanations? Cross-reference with change management records, scheduled maintenance windows, and known application behavior. Automated deployment tools, backup agents, and vulnerability scanners all generate log patterns that can trigger behavioral rules without representing actual threats.
- What is the broader context? Pull related events from the same source IP, user account, or host in the preceding 24 hours. A single anomalous authentication event means far less than an anomalous authentication event preceded by a phishing click and followed by an unusual outbound connection.
- What is the risk if this is real? Prioritize investigation based on the potential impact of the threat scenario the alert represents. A detection rule firing on a domain controller warrants faster response than the same rule firing on a developer workstation, even if the technical alert confidence level is identical.
This workflow can be partially automated through SOAR platforms, but the contextual judgment in steps three and four benefits from analyst review. The current threat landscape, which includes ransomware groups with established dwell times, money mule networks used to launder proceeds from fraud operations, and DDoS-for-hire infrastructure operated by actors with anti-detection expertise, requires analysts who understand the attack narrative rather than simply processing individual alerts mechanically.
Measuring Whether Your Log Analysis Actually Works
Detection capability is difficult to measure in the absence of known-bad activity. Organizations that wait for a real incident to discover detection gaps pay a high price for that feedback. A practical alternative is continuous validation through purple team exercises, where offensive security staff or red team contractors attempt realistic attack techniques against production systems while the security team attempts to detect them using existing log analysis capabilities.
Purple team exercises for log analysis should specifically test whether the detection pipeline captures: lateral movement via pass-the-hash or pass-the-ticket, persistence mechanisms including scheduled tasks and registry run keys, credential dumping via LSASS memory access, and data staging in cloud storage before exfiltration. Each technique generates specific log artifacts when the right sources are enabled and the right rules are in place. Testing confirms that the pipeline works end-to-end, from event generation through collection, normalization, detection, and alert delivery.
Mean time to detect (MTTD) is the primary metric that log analysis improvements should move. Organizations currently averaging detection times measured in days or weeks have structural gaps in their collection, correlation, or triage workflows. A target of detecting active intrusions within hours of initial access is achievable with mature log analysis infrastructure, though it requires investment in both the technical pipeline and the analyst workflows that act on it.
A Pragmatic Starting Point for Teams Building This Capability
Security teams with limited resources should sequence their log analysis investments rather than attempting to solve everything simultaneously. A practical build sequence prioritizes detection coverage for the highest-consequence threat scenarios first.
Start with authentication and DNS. These two log sources together cover initial access and command-and-control communication, which are the two phases where early detection has the greatest impact on attack outcomes. Enable full DNS query logging on all internal resolvers. Ensure Windows security event logs are forwarded from domain controllers with a 90-day retention policy. Normalize both sources to a common schema and build baseline deviation alerts against them.
Add endpoint process creation logs next. Sysmon, deployed with a community baseline configuration such as the SwiftOnSecurity template, provides dramatically better process visibility than native Windows logging at manageable storage cost. The combination of authentication, DNS, and process creation logs covers the majority of attacker techniques documented in current incident response reporting.
Expand to cloud API audit trails, network flow records, and application access logs in subsequent phases as collection infrastructure and analyst capacity allow. Each additional source increases detection coverage and correlation fidelity. The goal is a log analysis architecture where an attacker cannot move through the environment without generating a detectable pattern, regardless of how carefully they attempt to blend into legitimate traffic.
The logs already contain the answers. The question is whether the infrastructure, the detection logic, and the analyst workflows are configured to find them before the cost of not finding them becomes unacceptable.
