A Monday Morning That Started With One Odd Line
A financial services company running a hybrid cloud environment had been collecting logs for three years. The SIEM was configured, retention policies were in place, and alerts were firing regularly. The problem was that when investigators finally traced a data exfiltration incident back to its origin, the attacker had been present for twenty-six days. The entry point was a compromised service account. The lateral movement was slow and deliberate. Every single action had been logged. None of it had been correlated into a coherent threat story until after the damage was done.
That scenario plays out in organizations of all sizes, across every industry. The logs were there. The visibility was there. What was missing was a systematic approach to analyzing those logs for threat-relevant signal, rather than treating them as an audit trail to review after the fact.
This article walks through how to build log analysis into an active threat detection capability, with concrete examples drawn from real-world attack patterns and current threat activity.
What Attackers Leave Behind and Why It Matters
Every attacker action generates telemetry. Authentication events, process executions, network connections, file modifications, API calls, and service interactions all write to logs somewhere in your environment. The challenge is that defenders are looking at signal embedded in enormous volumes of routine activity. A typical enterprise generates billions of log events per day. An attacker operating carefully generates maybe a few hundred events that are genuinely anomalous, spread across that volume over days or weeks.
The 911 S5 botnet, which infected millions of residential IP addresses before being dismantled by law enforcement, demonstrated how patient threat actors can be. Operators of that infrastructure were making money for years by blending malicious traffic into legitimate residential ISP traffic. The same patience applies to intrusion operators. They move slowly, reuse legitimate tools, and deliberately avoid patterns that trigger obvious alerts.
Recent analysis of modified versions of the CIA's Hive attack toolkit, which has reportedly found its way into criminal markets, shows how sophisticated capabilities are democratizing. Teams that built their detection logic around catching obviously malicious tooling now face adversaries using tools that were originally designed to evade exactly the kind of detection most enterprises have deployed.
Log analysis for threat detection has to account for that sophistication. Detection built only on known bad signatures will miss the threats that matter most.
Building a Log Collection Foundation That Actually Supports Detection
Before you can analyze logs effectively, you need to collect the right ones in the right format. This sounds obvious but the gap between what organizations think they're collecting and what they're actually collecting is often significant.
Authentication and Identity Logs
Authentication logs from Active Directory, Azure AD, Okta, or whatever identity provider you're running are among the highest-value sources available. These logs record every authentication attempt, success, failure, token issuance, privilege elevation, and group membership change. Correlating these across your identity stack gives you visibility into credential-based attacks, which remain the most common initial access vector.
Collect Windows Security Event Log events 4624 (successful logon), 4625 (failed logon), 4648 (logon using explicit credentials), 4672 (special privileges assigned), 4768 and 4769 (Kerberos ticket events), and 4776 (NTLM authentication). These seven event IDs alone tell you an enormous amount about what's happening in your environment.
Endpoint Telemetry
Windows Event Logging with Sysmon deployed gives you process creation (Event ID 1), network connections from processes (Event ID 3), file creation (Event ID 11), registry modifications (Event ID 13), and process access (Event ID 10). Sysmon configuration quality matters significantly here. A poorly tuned Sysmon configuration generates so much noise that analysts stop reviewing the output. A well-tuned configuration from a maintained community schema like the SwiftOnSecurity config gives you actionable signal.
Linux endpoint logging through auditd provides equivalent visibility. Focus on execve syscalls for process execution, openat for file access, connect for network connections, and setuid for privilege changes. Forward these to your central logging infrastructure with consistent timestamp formatting and hostname enrichment.
Network Flow Data
NetFlow, IPFIX, or sFlow from network devices gives you a metadata-level view of all network communications without the storage overhead of full packet capture. Network flow data is particularly valuable for detecting lateral movement, identifying unusual connection patterns, and spotting data staging or exfiltration behavior. A workstation that normally communicates with ten internal hosts and three external domains suddenly communicating with forty internal hosts and twenty external domains is worth investigating.
Application and API Logs
Web application logs, API gateway logs, and database query logs fill in the gaps that network and endpoint telemetry leave. The recent research into SQL injection leading to remote code execution in LangGraph's checkpointer functionality is a good example of why application-layer logging is critical. The attack path in that case started with a SQL injection that was visible in application logs long before it escalated to code execution. Teams with proper application log collection and analysis could have caught the initial injection attempts as reconnaissance activity.
Turning Raw Log Data Into Threat-Relevant Detections
Log collection is table stakes. The analytical framework you apply to that data determines whether you catch threats or discover them in post-incident reviews.
Baseline Normal to Recognize Abnormal
Every detection capability depends on knowing what normal looks like in your specific environment. Generic thresholds pulled from vendor documentation will generate alert fatigue in some environments and miss real attacks in others. Invest the time to baseline actual behavior for the systems and users you're monitoring.
For authentication, that means understanding typical logon hours, typical source IPs, and typical authentication methods for each user and service account. A domain admin account that normally authenticates from two workstations during business hours generating Kerberos tickets from a new host at 2 AM is a detection opportunity. An overly sensitive rule that fires whenever any authentication happens outside business hours is a noise generator that trains analysts to ignore alerts.
For network behavior, baseline which internal hosts communicate with which other internal hosts, what external destinations are routinely accessed, and what typical data transfer volumes look like. Deviations from that baseline are where threats hide.
Correlation Rules That Catch Multi-Stage Attacks
Individual log events rarely tell the complete story of a compromise. Effective detection requires correlating events across sources and over time to identify attack sequences.
A practical example: a user account fails authentication from an external IP five times, then succeeds on the sixth attempt from the same IP. That single sequence is suspicious. Add to it that within ten minutes of that successful authentication, the same account queries Active Directory for domain admin group membership. Add further that the account then establishes an SMB connection to a file server it has never accessed before. Any single event in that chain has an innocent explanation. All three together in sequence represent a textbook credential-based intrusion attempt.
Build correlation rules that chain events across sources with time windows. Most SIEM platforms support this through rule chaining or sub-rule logic. The key parameters are the time window (tight enough to be meaningful, loose enough to catch slow attackers), the event sources that must all contribute (authentication logs, directory service logs, and network logs in the example above), and the entity that connects them (the user account).
Detecting Lateral Movement Through Authentication Patterns
Lateral movement consistently appears in authentication logs as a pattern of pass-the-hash or pass-the-ticket activity. Specific indicators include NTLM authentication (Event ID 4776) from hosts that normally use Kerberos, logon type 3 (network logon) events for service accounts that should only authenticate locally, and Kerberos ticket requests for services on hosts that the requesting account has no business accessing.
The Hive toolkit and similar implants that are now circulating in criminal markets after being repurposed from state-sponsored origins often use legitimate Windows authentication mechanisms specifically to blend into authentication log noise. Detection requires looking at the behavioral pattern, not just the individual event.
Privilege Escalation Indicators
Privilege escalation events are particularly valuable detection points because legitimate escalation in a well-managed environment is relatively rare and follows predictable patterns. Monitor for unexpected addition of accounts to privileged groups (Event ID 4728 for global security groups, 4732 for local groups), unexpected special privilege assignments at logon (Event ID 4672 for accounts that don't routinely receive special privileges), and service creation or modification (Event ID 7045 in the System log) from user-context processes.
Container environments add another dimension here. Kaspersky's analysis of container security risks highlights how privilege escalation within container environments often starts with exploiting misconfigurations or vulnerabilities that are visible in container runtime logs before they escalate to host compromise. If you're running containerized workloads, ensure your container runtime generates audit logs and those logs flow into your central analysis platform.
Specific Attack Patterns and How to Find Them in Logs
Credential Stuffing and Brute Force in Authentication Logs
Modern credential attacks against web applications and VPN portals often use distributed source IPs, which makes threshold-based detection on a per-source-IP basis ineffective. The detection pivot is to the target account or application, rather than the source.
Look for authentication failure spikes against a specific application across diverse source IPs. Look for sequential failures against many different accounts from the same source or small source range. Look for successful authentications that follow a period of failure from a different IP than the one that was failing, which is consistent with credential validation followed by actual use from a different node.
Data Staging and Exfiltration Signatures
Data exfiltration rarely happens instantly. Attackers typically spend time identifying valuable data, staging it in a compressed archive, and then moving it out. Each of those phases generates log events.
File system logs showing creation of large archive files (zip, rar, 7z) in unusual locations like temp directories or user profile paths are staging indicators. Network flow data showing an internal host generating large outbound transfers to a new external destination is an exfiltration indicator. DNS query logs showing queries for domains that were never queried before, followed by connection establishment, can indicate attacker-controlled infrastructure being used as an exfiltration endpoint.
The botnet infrastructure lessons from 911 S5 are relevant here. That botnet succeeded partly because exfiltration traffic was routed through residential IP addresses, making it look like ordinary user-generated traffic in network flow analysis. Detection in those cases requires looking at the behavioral profile of the internal host, not just the reputation of the external destination.
Living-Off-The-Land Binary Abuse
Modern attackers prefer using built-in system tools to avoid triggering endpoint security that might flag unknown executables. PowerShell, WMI, certutil, mshta, regsvr32, and similar binaries generate Sysmon process creation events that are detectable when the command-line arguments or parent processes are unusual.
PowerShell invocations with -EncodedCommand flags from non-administrative user contexts are suspicious. Certutil being called to decode a file that was recently downloaded is suspicious. WMI being used to create processes on remote hosts is almost always worth investigating. These patterns appear clearly in Sysmon Event ID 1 logs when command-line logging is enabled.
Enable PowerShell Script Block Logging (Event ID 4104) and Module Logging. These Windows logging features record the actual PowerShell code being executed, including code that has been obfuscated at the invocation level. Script block logging decodes and logs the underlying content, which makes it significantly harder for attackers to hide malicious PowerShell execution.
Operationalizing Log Analysis at Scale
Tiered Alert Priorities and Investigation Queues
Not all log-based detections require the same response urgency. A tiered priority system prevents analyst burnout while ensuring that high-confidence, high-severity detections receive immediate attention.
Tier one alerts represent high-confidence indicators of active compromise: interactive logon to a domain controller from a workstation using domain admin credentials outside of a change window, command-and-control traffic patterns from an internal host, or a Kerberoasting attack in progress. These require immediate response, measured in minutes.
Tier two alerts represent suspicious patterns that require investigation within hours: unusual service account activity, new external destinations being accessed from server systems, or PowerShell execution from user accounts that don't normally run scripts.
Tier three represents low-and-slow anomalies worth tracking over time: gradual increases in authentication failures for a specific account, incremental additions of file access permissions, or new network paths between systems that haven't historically communicated. These inform threat hunting workflows rather than driving immediate response.
Log Retention Policies That Support Investigations
The twenty-six-day intrusion described in the opening scenario required going back through three weeks of logs to reconstruct the attacker's timeline. Retention policies need to account for the reality that threat dwell time frequently exceeds thirty days. The current industry baseline recommendation from frameworks like NIST and CIS is ninety days of hot storage with one year of cold storage for most log sources. Security-critical sources like authentication logs and privileged account activity warrant longer retention.
Tiered storage using cloud object storage for historical logs significantly reduces the cost of meeting these retention targets. The key requirement is that logs stored in cold storage remain searchable on demand. An investigation that requires a two-day wait for log retrieval from tape is not a functional investigation capability.
Enrichment and Context at Query Time
Raw log events have limited investigative value. Enrichment adds context that makes them actionable. Useful enrichment includes asset information (what is this system, what data does it hold, who owns it), user context (what department, what access rights, what normal behavior looks like), threat intelligence (is this IP or domain associated with known malicious activity), and geolocation for external IPs.
The caveat on geolocation enrichment is important. As several recent analyses have noted, IP geolocation data has meaningful accuracy limitations, and attackers routinely use VPNs, proxies, and compromised infrastructure to make traffic appear to originate from unexpected locations. Geolocation is one data point among many, not a definitive attribution mechanism.
Threat Hunting Through Logs When Alerts Aren't Firing
Alert-driven detection catches known patterns. Threat hunting through logs catches attackers who have successfully evaded automated detection. Structured hunting uses hypotheses derived from threat intelligence and known attack patterns to query logs proactively.
A practical hunting hypothesis: if an attacker has compromised a service account in the environment and is using it for lateral movement, what would that look like in authentication logs? The hunter queries for service accounts authenticating interactively (logon type 2 or 10), service accounts establishing network connections to hosts outside their normal scope, and service accounts that have been used from more source IPs in the last thirty days than in the prior quarter.
Hunting queries like this don't require a detection rule to fire. They're analyst-driven investigations of log data looking for patterns consistent with known attack techniques. The output is either confirmation that the environment is clean, discovery of malicious activity, or identification of configuration problems worth fixing.
The MITRE ATT&CK framework provides a structured library of adversary techniques, each of which has observable log artifacts. Working through ATT&CK tactics systematically and building hunting queries for high-priority techniques in your threat model is a sustainable way to mature your log analysis capability over time.
Applying This to Current Threat Conditions
The current threat landscape makes comprehensive log analysis more critical than it has been at any previous point. State-sponsored tooling is finding its way into criminal markets. Sophisticated botnets that persisted for years in residential ISP space demonstrate how patient and deliberate modern threat actors operate. The expansion of attack surfaces through containers, cloud APIs, and AI-integrated services creates new log sources that many organizations aren't collecting or analyzing.
The children's data risk research highlights another dimension: some breaches only become apparent as damage years after the initial compromise. Long-term log retention and periodic review of historical data isn't just a compliance requirement, it's a practical necessity for catching slow-moving threats and understanding the full scope of incidents that appear limited at first review.
For teams running AI-integrated workloads, the application-layer log analysis discipline discussed earlier applies directly to AI API interactions. SQL injection attacks against components like LangGraph illustrate that AI pipeline components carry the same vulnerability classes as traditional web applications and require the same logging and monitoring discipline.
Building the Habit of Using Logs Proactively
The organizations that catch threats early share a common characteristic: they use logs continuously, not just after something goes wrong. That means scheduled hunting sessions, weekly reviews of alert trend data to identify emerging patterns, and regular tuning of detection rules based on what's being missed or generating noise.
It also means treating log analysis as a skill that requires deliberate development. Analysts who understand what normal authentication traffic looks like, what legitimate administrative tool usage looks like, and what typical data transfer patterns look like in their environment can identify anomalies that no automated rule will catch. That knowledge comes from time spent in logs during quiet periods, not just during incidents.
The log data is already there. The question is whether your team is reading it.
