The Breach That Was Already Documented
A mid-sized financial services firm experienced a credential-stuffing attack that compromised roughly 4,000 customer accounts over eleven days. The attack was methodical: low-volume login attempts distributed across dozens of IP addresses, each one keeping request rates just under their alerting thresholds. When forensic responders pulled the logs after the breach was reported by customers, every step of the attack was there. Authentication logs showed the enumeration. Application logs showed the successful logins. Downstream logs showed the data access. The SIEM had ingested all of it. Nobody received an alert.
This is not an unusual story. The problem was not a lack of log data. The problem was that the organization had built its detection logic around individual events rather than correlated sequences, set thresholds calibrated to old attack patterns, and treated log analysis as a compliance function rather than an operational one. If you work in a SOC or manage infrastructure for an organization that handles sensitive data, this scenario should feel uncomfortably familiar.
Log analysis for threat detection is one of the most powerful tools available to defenders, and one of the most consistently underutilized. This article covers the practical mechanics of doing it well: what to collect, how to structure detection logic, where analysts go wrong, and how emerging threat patterns in 2026 are making the discipline more demanding.
What Logs Actually Contain (Versus What Teams Think They Contain)
Security teams often treat log collection as a solved problem. Agents are deployed, a SIEM ingests the data, and dashboards show green. The reality is that most environments have significant gaps in log coverage that only become visible during incident response.
The core categories of logs that matter for threat detection are authentication logs, network flow data, endpoint process logs, application-layer logs, and DNS query logs. Each layer catches different attacker behaviors, and the absence of any one of them creates blind spots that sophisticated threat actors reliably exploit.
Authentication Log Gaps
Authentication logs from Active Directory, Okta, Azure AD, or equivalent identity providers tell you who authenticated, from where, at what time, using what method, and whether it succeeded. What many teams miss is that these logs frequently do not capture the full context of a session. A successful SAML assertion from a cloud identity provider may show the authentication event but not the originating IP if log forwarding is misconfigured. Legacy on-premises applications often write authentication events to local logs that are never forwarded to the SIEM at all.
The PhantomRPC privilege escalation technique, disclosed recently, illustrates why Windows RPC and local authentication logs deserve more attention than they typically receive. PhantomRPC abuses Windows Remote Procedure Call interfaces to escalate privileges without touching many of the indicators that endpoint detection tools watch. The activity does generate log entries, specifically in Windows Security event IDs 4688 (process creation), 4697 (service installation), and in RPC audit logs if auditing is enabled. Most environments do not have RPC auditing enabled, and even those that do often fail to forward those logs to their SIEM.
Application Log Neglect
Web application logs, database query logs, and API gateway logs are the most frequently undertapped sources in mid-market security programs. When JanelaRAT, a financial remote access trojan targeting Latin American users, establishes persistence on a compromised host, its command-and-control traffic often appears in proxy or web gateway logs before it appears anywhere else. Organizations that route employee traffic through a proxy but fail to send those logs to their SIEM are flying partially blind.
Application logs also capture behaviors that network-layer tools cannot see. A compromised account accessing a banking application may produce perfectly normal network traffic while generating deeply anomalous application-layer events: accessing account records in bulk, exporting data to unusual formats, or querying fields that the account has never accessed before.
Structuring Detection Logic Around Attack Sequences
The credential-stuffing scenario described at the opening of this article failed because detection rules were written around individual events. A single failed login is noise. Two hundred failed logins across forty IP addresses targeting the same fifty usernames over six hours is an attack. The difference is correlation across time and context.
Building Sequence-Based Rules
Effective log-based threat detection requires rules that operate on sequences of events rather than single occurrences. Most modern SIEMs support this through some form of event correlation or behavioral analytics. The implementation details vary by platform, but the underlying logic follows a common pattern.
Consider a rule targeting lateral movement after initial compromise. The sequence you are looking for might be: a workstation account authenticates successfully to an internal host it has never accessed before, that same account then runs a network reconnaissance command (visible in process creation logs), and within thirty minutes, authentication events appear for the same account on two additional internal hosts. No single one of these events is inherently malicious. The sequence is. Building that rule requires that all three log sources (authentication logs, process creation logs, and lateral movement indicators) be correlated in the same detection context with a time-bounded window.
Threshold Calibration
Thresholds for anomaly-based rules need to be derived from your own environment's baseline, not from vendor defaults or industry benchmarks. A development team that deploys code multiple times daily will generate patterns in CI/CD logs that look alarming against a generic baseline but are entirely normal for that organization.
The practical approach is to run candidate rules in monitor-only mode for two to four weeks, observe the distribution of triggering events, and use that data to set thresholds that balance sensitivity and false positive rate. Document what normal looks like for your environment. When attack patterns shift, as they frequently do, you need a baseline to measure deviation against.
High-Signal Log Sources That Most Teams Underuse
DNS Query Logs
DNS logs are among the highest-value sources for threat detection and among the most commonly neglected. Nearly every category of malware, from commodity stealers to sophisticated APT tooling, uses DNS at some point. Command-and-control infrastructure relies on DNS resolution. Data exfiltration via DNS tunneling encodes data in query strings. Phishing infrastructure is set up and torn down rapidly, but the DNS queries to those domains leave a record.
GopherWhisper, a recently identified malware family with diverse capability modules, uses DNS-based C2 communications that blend into normal query volumes but reveal themselves through query frequency, domain entropy analysis, and the pattern of newly-registered domains being queried from endpoints. None of that analysis is possible without DNS query logs at the resolver level, not just firewall DNS logs.
Passive DNS logging at your recursive resolver, whether that is an internal Bind or Unbound instance, a cloud DNS service, or a protective DNS provider, gives you a queryable record of every resolution request made on your network. Combine that with threat intelligence feeds of malicious domains, and you have a detection layer that catches threats at the resolution stage before a connection is ever established.
Process Creation and Command-Line Logs
Windows event ID 4688 with command-line auditing enabled, or Sysmon event ID 1, captures process creation with full command-line arguments. This is one of the richest sources available for detecting post-exploitation activity, living-off-the-land techniques, and persistence mechanisms.
When the Scattered Spider group (whose member Tyler Buchanan recently pleaded guilty to federal charges) conducted social engineering campaigns that led to endpoint access, the subsequent activity almost universally appeared in process creation logs: PowerShell running encoded commands, legitimate tools like PsExec being invoked with unusual arguments, credential dumping utilities being executed. The challenge is not that these logs lack signal. The challenge is that organizations either do not have command-line auditing enabled or generate so much process creation noise that analysts cannot identify the signal without automated detection rules.
A practical starting point is to build detection rules around process parent-child relationships that attackers commonly exploit. Office applications spawning PowerShell, Windows Script Host spawning cmd.exe, and mshta.exe spawning any child process are all high-fidelity indicators that warrant immediate investigation. These rules generate very few false positives in most environments and catch a wide range of initial access and execution techniques.
File Integrity and Access Logs
File system audit logs capture access to sensitive files, modifications to configuration files, and changes to executable directories. For organizations dealing with threats like the FakeWallet iOS crypto stealer or NGate's trojanized NFC payment app, the relevance on the server side is to the backend infrastructure those threats communicate with. When a fraudulent app harvests credentials or payment data, that data lands somewhere. Monitoring backend application servers for anomalous file creation, unexpected write operations to data directories, or access to credential stores by service accounts outside normal operational hours can reveal that exfiltration is occurring even when network-layer controls fail to catch it.
Log Retention and the Forensic Minimum
Detection only works on logs you have. Post-incident forensics only works on logs you kept. These two requirements pull in opposite directions because storage costs money, and verbose logging at scale generates enormous volumes of data.
The practical minimum retention period for security-relevant logs is ninety days in hot storage (immediately queryable) and one year in cold storage (retrievable within hours). This is based on the reality that many breaches are not discovered for weeks or months after initial compromise. The Verizon Data Breach Investigations Report consistently shows median dwell times measured in weeks. If your logs roll over after thirty days, you will be conducting forensic investigations with incomplete data.
The cost-effective approach to meeting this retention requirement is tiered storage: high-verbosity, high-value logs (authentication, DNS, process creation, network flow summaries) in hot storage for ninety days, then compressed and moved to object storage like S3 or Azure Blob for the remainder of the year. Most SIEM platforms support tiered storage natively or through integration with cloud storage services. The query performance for cold tier investigations will be slower, but the data will be there when you need it.
Practical Log Collection Architecture
Centralization Without Single Points of Failure
Log collection pipelines that route everything through a single aggregation point create a critical dependency. If that aggregator goes down during an active incident, you may lose log continuity at exactly the moment you most need it. Architects often overlook this because SIEMs are treated as observation systems rather than operational ones, but the observability of your detection infrastructure is itself a security property.
A resilient architecture uses local buffering at the source (most modern log agents support disk-backed queues), a minimum of two aggregation tiers in different availability zones, and explicit monitoring of log pipeline health with alerting on source dropout. When a host stops sending logs, that silence is itself a potential indicator. Hosts that go quiet during an active investigation have sometimes been compromised and had their logging agents stopped or misconfigured by an attacker.
Normalization and Schema Consistency
Logs from different sources use different field names, timestamps, and formats. A Windows Security event log represents a user account differently than a Linux PAM log, which represents it differently than an AWS CloudTrail event. Without normalization, correlation rules break down because the same conceptual entity (a user account, a source IP address, a process name) is not consistently represented across events.
Invest in normalization at the collection layer, not the query layer. Transforming log data into a consistent schema when it arrives, rather than translating fields at query time, makes detection rules simpler, faster, and less prone to missing events due to field mapping errors. Common schemas like the Elastic Common Schema (ECS), OCSF (Open Cybersecurity Schema Framework), or vendor-specific normalized schemas provide a starting framework that can be extended for your environment.
Responding to What Logs Reveal
Triage Prioritization
Log-based detection generates alerts. Effective security operations means triaging those alerts in a way that gets analysts working on the highest-priority cases first. A useful triage framework considers three factors: the confidence of the detection (how specific and validated is the rule that fired?), the asset criticality of the affected system (is this a domain controller or a test workstation?), and the presence of corroborating signals from other log sources.
An alert that fires on a single authentication log event should be deprioritized compared to an alert that fires because authentication logs, DNS logs, and process creation logs all show consistent indicators on the same host within a thirty-minute window. Build your triage workflows to surface this kind of multi-source corroboration automatically rather than requiring analysts to manually pivot between data sources for every alert.
What Logs Cannot Tell You
Log analysis has limits that are worth stating clearly. Logs record what systems observed, which means an attacker who operates entirely within the trusted execution context of a legitimate process may not generate log entries that look different from normal behavior. Ransomware groups have refined their initial access and lateral movement to specifically minimize log artifacts. The ransom note that appears at the end of an attack rarely contains any indication of how long the attacker was present or what data they accessed, because by that point the attacker has already finished their work across infrastructure that logs never fully captured.
This is not an argument against log analysis. It is an argument for combining log analysis with endpoint detection and response (EDR) telemetry, network detection tools, deception technologies, and threat hunting workflows that go looking for threats rather than waiting for alerts. Log analysis is one layer in a defense-in-depth approach, not a replacement for the others.
Putting It into Practice
If you are rebuilding or improving log-based threat detection in your environment, a practical sequence of priorities looks like this:
- Audit your log coverage. Identify which systems are sending logs to your SIEM and which are not. Pay particular attention to authentication infrastructure, DNS resolvers, and critical application servers.
- Enable command-line auditing on Windows endpoints. This is a configuration change in Group Policy that dramatically increases the value of process creation logs at minimal performance cost.
- Build five to ten sequence-based detection rules focused on your highest-risk attack vectors. Do not try to cover everything at once. Start with initial access to persistence sequences, and credential access to lateral movement sequences.
- Run those rules in monitor-only mode for two to four weeks. Calibrate thresholds against observed false positive rates.
- Review your log retention configuration. Confirm that high-value logs are retained for at least ninety days in a queryable tier.
- Establish a process for reviewing log pipeline health. Treat source dropout as a potential security event.
Log analysis will not catch every threat. Sophisticated attackers specifically design their operations to minimize log artifacts, and the npm threat landscape alone, with its ongoing supply chain attack surface that continues to expand through 2026, demonstrates how attacker tradecraft evolves faster than most detection programs adapt. But well-implemented log analysis catches a large proportion of real-world attacks because most attacks are not sophisticated in practice. They use known techniques, predictable sequences, and infrastructure that leaves traces. Your logs already saw it. The work is building the capability to see what they saw.
