The Incident That Started With a Printer
A mid-sized logistics company received a ransom note printed across every networked printer in their building. The BitLocker encryption had already run. Backups were intact, so the immediate damage was limited, but the forensic review revealed something more troubling than the ransomware itself: the attacker had been inside the network for eleven days. During that time, authentication logs recorded seventeen successful logins from a service account that had not been used in four months. Event logs on three servers showed unusual scheduled task creation. DNS query logs captured dozens of lookups to domains registered within the previous week. Every piece of evidence was sitting in existing log infrastructure. None of it had generated an alert.
This scenario maps closely to the wave of small-ransom, printer-targeting extortion campaigns documented in recent threat intelligence reporting, where attackers rely on low-and-slow persistence rather than noisy exploitation. The logs existed. The gap was in what teams chose to collect, correlate, and monitor.
This article is for security operations teams and IT administrators who already have logging infrastructure and want to understand what practical, effective threat detection from logs actually requires, beyond the myths about what log analysis is supposed to accomplish.
What Logs Actually Represent Versus What Teams Assume They Represent
The most common assumption in enterprise environments is that logs are a compliance artifact first and an investigative tool second. SIEM deployments get built around satisfying audit requirements rather than detecting adversary behavior. The result is environments where terabytes of firewall deny logs are faithfully stored while Windows Security event logs from domain controllers are either missing, filtered to the point of uselessness, or retained for only seventy-two hours.
Logs represent behavioral telemetry. Every log entry is a record of something a system did, or something that was done to it. Authentication logs record who claimed to be whom, from where, and at what time. Process creation logs record what ran, what spawned it, and what arguments it carried. Network flow logs record which systems talked to which other systems, on what port, for how long, and how much data moved. DNS logs record what names systems tried to resolve, which reveals intent before a connection is fully established.
The threat detection value of any log source comes from behavioral baseline comparison, not from individual entry inspection. A single successful login from an unusual location means little in isolation. The same login, correlated with a spike in file enumeration events on a sensitive share thirty minutes later, followed by an outbound DNS query to a newly registered domain, represents a credible intrusion indicator chain.
Building a Log Collection Architecture That Covers Real Attack Paths
Before detection logic matters, collection coverage determines what is even possible. Many enterprise environments have significant gaps that attackers exploit by simply operating in unmonitored territory. The following areas represent the highest-value collection targets for threat detection specifically, not for compliance.
Authentication Event Coverage
Windows Security Event ID 4624 records successful logon events. Event ID 4625 records failed logons. Event ID 4768 and 4769 cover Kerberos ticket requests and service ticket operations. Event ID 4776 covers NTLM authentication attempts. Together, these four event types tell the story of lateral movement, credential abuse, and pass-the-hash or pass-the-ticket activity. Collection needs to include domain controllers, servers hosting sensitive services, and workstations — not just domain controllers in isolation.
For Linux environments, /var/log/auth.log and /var/log/secure capture SSH authentication, sudo usage, and PAM events. SSH logs in particular become critical when attackers pivot through jump hosts or use compromised service accounts for remote access. The Siemens ROX II zero-day research published recently demonstrated exactly this attack path: initial access to an edge device, followed by lateral movement through SSH to internal systems, with each hop leaving authentication log traces that a properly instrumented environment would have surfaced.
Process Execution and Command Telemetry
Windows Event ID 4688 with command-line auditing enabled, or Sysmon Event ID 1, captures process creation with parent process relationships and command arguments. This is the single most valuable log source for detecting living-off-the-land techniques, where attackers use built-in system tools like PowerShell, WMI, certutil, and BITSAdmin to carry out malicious operations that look like legitimate administrative activity at first glance.
Sysmon provides richer telemetry than native Windows auditing and should be deployed with a maintained configuration file rather than default settings. The SwiftOnSecurity Sysmon configuration is a well-documented starting point that covers the most common attacker techniques. Events worth prioritizing include network connections initiated by scripting engines, driver loading events, and named pipe creation, which is a common lateral movement channel in enterprise environments.
DNS Query Logging
DNS is the nervous system of most attacks. Command-and-control beaconing, data exfiltration, and initial payload delivery all touch DNS. Enabling query logging on internal resolvers or deploying a DNS security layer that logs all queries gives defenders visibility into attacker intent that firewall logs often miss entirely, because the DNS query happens before the connection attempt that a firewall would see.
The Rondo campaign targeting GeoServer vulnerabilities, documented in recent SANS Internet Storm Center reporting, used DNS-based staging to deliver payloads after initial exploitation. DNS logs in those environments would have shown lookups to newly registered infrastructure well before payload execution completed.
Web and Application Access Logs
Web server access logs carry more than request details. They carry behavioral fingerprints. Scanning activity produces characteristic patterns: sequential path enumeration, rapid status code 404 responses, unusual User-Agent strings, and request timing intervals that no human browser produces. Attackers targeting exposed web applications, including those running vulnerable versions of GeoServer or similar geospatial platforms, generate distinctive log signatures during reconnaissance that precede exploitation attempts by hours or days.
Application logs from authentication endpoints deserve particular attention. Failed authentication events from web applications should be normalized and fed into the same pipeline as Windows authentication failures. Distributed credential attacks often spread attempts across many source IPs precisely to avoid triggering per-IP thresholds, but they still produce elevated aggregate failure rates against the same set of target accounts.
Correlation Rules That Catch Real Attacker Behavior
Raw log collection without correlation produces alert fatigue or silence, both of which serve attackers. Effective correlation means defining sequences of events that represent meaningful attacker behavior rather than individual anomalies.
Impossible Travel and Authentication Sequencing
A user account authenticating successfully from a domestic IP at 09:00, then from a foreign IP at 09:45, represents a physical impossibility. This pattern, known as impossible travel, is simple to implement as a correlation rule and reliably surfaces account compromise. The rule requires storing the last successful authentication IP and timestamp per account, then flagging any subsequent authentication that implies travel faster than physically achievable.
More sophisticated variations include authentication source diversity rules: a single account authenticating from more than four distinct subnets within a two-hour window, or a service account authenticating interactively from a workstation when its normal behavior is only non-interactive logons from a single server.
Beaconing Detection Through DNS and Network Flow Analysis
Malware maintaining command-and-control communication beacons at regular intervals, producing a timing signature in network flow logs and DNS query logs that is statistically distinguishable from normal application traffic. The detection technique involves calculating the variance in timing intervals for connections from a single internal host to a single external destination. Low-variance, periodic connections to destinations that do not appear in the baseline of known-good traffic are strong beaconing indicators.
Implementing this in a SIEM requires bucketing connection events by source IP and destination IP over rolling time windows and calculating the coefficient of variation for inter-connection intervals. A threshold of less than 0.2 coefficient of variation with at least eight samples in a four-hour window catches the majority of beacon patterns while keeping false positive rates manageable in most enterprise environments.
Lateral Movement Through Authentication Chain Analysis
Lateral movement produces a graph structure in authentication logs: source accounts authenticate to one system, then from that system to another, then another. A compromised workstation used as a pivot point will appear as an authentication source in server event logs rather than only as a destination. Windows Event ID 4648, which records explicit credential use, is particularly valuable here because it fires when accounts are used to authenticate to remote systems, which is the core lateral movement action.
Building a time-windowed authentication graph and looking for source nodes that were themselves recently authenticated to from external or unusual sources identifies pivot chains. The key insight is that the log event on the destination system identifies the source, and that source's own logs show that it was itself recently accessed from somewhere anomalous.
Privilege Escalation and Persistence Indicators
Windows Event ID 4672 records special privilege assignment, which fires when accounts with sensitive privilege sets log on. Unexpected 4672 events for accounts that should not carry administrative privileges indicate either privilege escalation or an attacker operating with a previously compromised high-privilege account. Combined with Sysmon Event ID 13, which records registry value modifications, defenders can detect common persistence mechanisms including run key modifications and service installation events that indicate an attacker establishing a foothold.
Scheduled task creation via Windows Event ID 4698 should be baselined aggressively. Legitimate scheduled task creation is relatively rare outside of software installation windows. Any scheduled task creation outside change windows, particularly tasks invoking scripting engines with encoded commands, deserves immediate investigation.
Log Retention and the Detection Window Problem
Detection only works within the retention window. If logs are kept for seventy-two hours and an attacker maintains persistence for eleven days before acting, the initial access artifacts are gone before anyone knows to look. The ESET Threat Report for the first half of 2026 confirms that attacker dwell time in network environments remains measured in days to weeks for many incident categories, despite increased defender awareness.
Hot storage, where logs are available for immediate query, should cover a minimum of thirty days for high-value sources including authentication logs, process execution logs, and DNS query logs. Ninety days is more appropriate for environments with meaningful threat exposure. Cold storage for compliance and forensic purposes can extend further without impacting real-time detection, provided the retrieval process is documented and tested before an incident requires it.
Tiered retention strategies make this economically viable. Not all log sources need the same retention profile. Windows Security event logs from domain controllers warrant longer hot retention than, for example, successful HTTP 200 responses from a low-sensitivity web application.
The GeoServer and Edge Device Log Problem
Recent exploitation campaigns targeting GeoServer vulnerabilities illustrate a gap that affects many environments: edge devices and specialized application servers often generate logs in formats that SIEM systems do not parse cleanly, so teams either skip them or accept incomplete parsing that drops important fields.
GeoServer exploitation attempts produce distinctive patterns in web server logs: OGC filter parameter injection sequences, unusual geometry operation requests, and error responses that indicate probe-then-exploit behavior. These patterns are readable once the logs are properly parsed and the field mappings are correct, but they require parser development effort that many teams deprioritize.
The same problem applies to operational technology environments running platforms like Siemens ROX II, where the recent zero-day research demonstrated that shell access could be achieved through a chain of vulnerabilities. OT and ICS systems frequently have limited logging capability, but where logs exist, particularly authentication and configuration change logs, they must be collected. Attackers understand that OT log coverage is poor and actively use OT segments as staging ground for lateral movement back into IT environments.
Responding When the Logs Tell You Something Is Wrong
Detection is the beginning of a workflow, not the end. When correlation logic fires on a credible indicator chain, the response sequence matters as much as the detection itself.
Initial Triage and Scope Assessment
The first task on any triggered alert is determining scope: how many systems are involved, what accounts appear in the activity, and what time range the activity spans. A query across authentication logs for all activity by the flagged account over the previous thirty days often reveals that the initial alert represents only the visible portion of a longer intrusion.
Pull the full account activity timeline first. Identify every system the account touched, every process that account spawned, and every network connection initiated during the suspicious window. This scope assessment drives both containment decisions and evidence preservation priorities.
Containment Without Destroying Evidence
Isolating a compromised system from the network stops active attacker activity but preserves the forensic state of the system. Shutting down a system instead of isolating it may interrupt attacker activity but destroys volatile evidence including running processes, network connections, and memory artifacts that may be the only record of attacker tooling.
Authentication token revocation for compromised accounts should happen in parallel with system isolation, and active directory should be checked for any group membership changes, new accounts, or modified service account configurations that the attacker may have made during their presence.
Closing the Detection Gap After an Incident
Every incident reveals at least one detection gap that existed before the compromise. The post-incident log review should specifically document what artifacts were present in logs that did not generate alerts, and why: whether the log source was not collected, the retention window was too short, the correlation rule did not exist, or the rule existed but was misconfigured or suppressed.
Converting these findings into specific detection improvements, new correlation rules, extended retention for relevant log sources, and corrected parsing for missed log formats, closes the gap for future incidents rather than simply responding to the current one.
Surveillance Hardware and the Log Coverage Blind Spot
Recent reporting on cybercriminals selling access to compromised Chinese-manufactured surveillance cameras highlights a category of devices that generate network traffic, store credentials, and often have administrative interfaces, but that most organizations never integrate into their log collection infrastructure. IP cameras, building access control systems, and similar IoT devices authenticate users, log configuration changes, and initiate network connections to cloud management platforms.
Where firmware supports syslog export, these devices should be added to the log collection pipeline. Where they cannot generate usable logs, their network behavior should be baselined from flow data and monitored for deviations: unexpected outbound connections, authentication from unusual source addresses, and traffic patterns inconsistent with their operational role.
Ransomware and the Logs That Precede It
Ransomware deployment is the last phase of a multi-stage attack. The logs preceding ransomware execution almost always contain a readable intrusion story: initial access, credential harvesting, lateral movement, reconnaissance of backup infrastructure, and finally encryption. The challenge is not that logs are absent; it is that no one read them until after the ransomware ran.
Recent threat intelligence confirms that ransomware campaigns continue accelerating in volume regardless of AI involvement. The operational patterns remain consistent: attackers invest significant time in pre-ransomware reconnaissance, and that reconnaissance leaves traces. Volume shadow copy enumeration, backup agent configuration queries, and domain controller replication queries all appear in logs days or weeks before encryption begins.
Building detection rules specifically for pre-ransomware behaviors, rather than trying to detect encryption activity after it starts, shifts the detection window earlier in the attack chain and creates opportunities for containment before damage occurs.
Practical Starting Points for Teams With Limited Resources
Not every organization operates a mature SOC with dedicated threat hunting capability. For teams with constrained resources, prioritization matters more than comprehensiveness.
- Enable Windows command-line auditing on all servers and workstations if Sysmon is not deployed. This single configuration change adds command arguments to process creation events and dramatically increases detection coverage for living-off-the-land attacks.
- Enable DNS query logging on internal recursive resolvers. The storage cost is low relative to the detection value, and DNS logs frequently reveal malware that produces no other immediately visible indicators.
- Audit service account behavior as a dedicated detection focus. Service accounts have predictable behavior profiles and any deviation, interactive logon, authentication from an unexpected source, or new group membership, represents a high-fidelity indicator of compromise or misuse.
- Retain authentication logs for at least thirty days in a queryable format. Many intrusions are only discovered after initial detection of a secondary indicator, and tracing the full scope requires historical authentication data that short retention windows destroy.
- Test correlation rules quarterly by simulating the behaviors they are designed to detect. Rules that were valid when written can break silently when log formats change, field names are modified during SIEM upgrades, or source systems change their logging behavior after patches.
What Effective Log Analysis Actually Requires
Log analysis for threat detection is a continuous operational discipline, not a technology deployment. The technology, whether a SIEM, a data lake, or purpose-built detection tooling, provides the capability. The detection value comes from the collection architecture, the correlation logic, the retention policy, and the operational process for acting on what the logs reveal.
Teams that treat log analysis as an infrastructure problem to be solved once and maintained minimally will continue finding, as the logistics company discovered, that the evidence of an intrusion was present throughout, and the gap was in the operational practice around it. Teams that treat it as a continuous detection engineering discipline build the capability to catch attackers while they are still in the reconnaissance and lateral movement phases, before the printers start printing ransom notes.
