The Threat Landscape That Makes Logs Matter More Than Ever
Ransomware attacks are climbing. Modified CIA implants like the repurposed Hive toolkit are circulating in criminal marketplaces, giving less sophisticated actors access to enterprise-grade intrusion capabilities. PhantomRPC is demonstrating fresh privilege escalation paths through Windows RPC, and threat actors are selling access to compromised surveillance camera infrastructure at scale. Each of these threats leaves traces in logs. The question is whether those traces get read before damage compounds.
The April 27th Threat Intelligence Report cycle, alongside the ISC SANS stormcast from early May 2026, both highlighted a consistent pattern: attackers are spending more time inside networks before detection, and the evidence of their activity was present in log data that nobody acted on in time. Log analysis is not a passive archiving exercise. It is one of the most direct ways to detect an intrusion in progress, provided it is done with the right architecture, correlation logic, and operational discipline.
This article covers how to build a log analysis practice that actually produces actionable threat detection, with specific focus on the scenarios cybersecurity professionals are facing right now.
Why Log Data Is Still Where Attacks Get Exposed
Attackers have adapted to evade endpoint detection. They abuse legitimate tools, use signed binaries, and route traffic through commercial hosting infrastructure to blend into normal network noise. But they cannot avoid generating log entries. Every authentication attempt, DNS resolution, process spawn, and network connection writes a record somewhere. The challenge is not a lack of evidence. It is the volume, the distribution, and the lack of correlation across those sources.
When the modified Hive C2 implant began appearing in criminal markets, defenders who detected it consistently did so through log correlation rather than signature-based detection alone. The implant communicated over HTTPS with certificates that looked legitimate, but the connection patterns, the timing intervals, and the processes initiating those connections told a different story when logs were reviewed together rather than in isolation.
The same principle applies to ransomware precursors. Groups deploying ransomware today rarely execute the final payload on day one. They establish persistence, move laterally, enumerate credentials, and exfiltrate data over days or weeks. Every one of those stages leaves log artifacts. Teams that detected the intrusion early did so because their log analysis caught the precursor activity, not because an alert fired when encryption started.
The Log Sources That Actually Matter for Threat Detection
Not all log sources contribute equally to threat detection. Teams that pipe everything into a SIEM without prioritizing their sources end up with storage costs and alert fatigue instead of detection capability. The following sources should be treated as high-priority for active threat hunting and correlation.
Windows Event Logs
Event IDs 4624, 4625, 4648, 4672, 4688, and 4698 cover authentication events, process creation, and scheduled task creation. Process creation logging (4688) requires explicit enablement via Group Policy and the addition of command-line auditing. Without command-line logging, you see that a process spawned but not what arguments it was called with, which eliminates much of the detection value for fileless attacks and living-off-the-land techniques.
Event ID 7045 captures new service installations. Attackers who gain SYSTEM privileges through techniques like PhantomRPC-style privilege escalation via Windows RPC often establish persistence by registering a malicious service. A spike in 7045 events outside of change windows is a reliable early indicator.
DNS Query Logs
DNS logs are underutilized by most teams, yet they provide one of the clearest windows into command-and-control activity. Beaconing implants resolve their C2 domains on predictable intervals. Exfiltration via DNS tunneling generates abnormally long query strings or high query volumes to a single domain. Data from the Cisco DoS vulnerability disclosures this year reinforced that network device logging, including DNS, needs to be treated as critical security telemetry rather than operational noise.
Enable query logging on internal resolvers and forward those logs to your SIEM or log aggregation platform. Set up alerts for NXDomain spikes from individual hosts, which indicate DNS-based C2 beaconing where domains are algorithmically generated, and for unusually long query strings that suggest tunneling.
Proxy and Web Gateway Logs
HTTP and HTTPS proxy logs show outbound connection attempts, user-agent strings, destination URLs, and response sizes. The GoDaddy ManageWP phishing campaign that abused Google Ads for credential harvesting left consistent proxy log signatures: users clicking through to lookalike domains, followed by POST requests to attacker-controlled infrastructure that returned redirect responses. Defenders who reviewed proxy logs for POST requests to newly registered domains caught the activity before credentials were abused.
Web gateway logs also help identify when compromised surveillance camera infrastructure is being accessed internally, which matters given the active market for access to those devices. Internal hosts polling external camera management endpoints on non-standard ports deserve immediate investigation.
Authentication and Identity Logs
Active Directory logs, Azure AD sign-in logs, and VPN authentication records need to be correlated together. Authentication from a new country, followed by lateral movement attempts using the same account two hours later, is a textbook account takeover pattern. Neither log individually triggers a confident alert. Together, they paint a clear picture.
For cloud environments, AWS CloudTrail, Azure Activity Logs, and GCP Audit Logs are the equivalent. Pay particular attention to IAM policy changes, new API key generation, and cross-account role assumptions, all of which are common in cloud-targeted intrusions.
Firewall and NetFlow Data
Firewall logs capture allowed and denied connections. NetFlow or IPFIX data captures connection metadata including byte counts and duration without payload content. Together, they help detect beaconing by identifying hosts that make periodic outbound connections of consistent size and duration to the same destination. The vm2 sandbox escape vulnerability that allowed code execution on host systems was followed by outbound connection attempts from affected hosts; firewall logs that captured those connections were the first detection signal in several environments.
Correlation: Where Individual Logs Become Threat Detection
A single failed authentication event is noise. Fifty failed authentication events from the same source IP across twenty accounts in three minutes is a credential stuffing attempt. The difference is correlation, which requires a structured approach to log aggregation and rule development.
Building Correlation Rules That Reflect Real Attack Chains
Effective correlation rules are built around attack chains rather than individual events. Take the ransomware precursor pattern. The typical chain looks like this: initial access via phishing or credential abuse, followed by reconnaissance commands (net user, whoami, ipconfig), followed by lateral movement using PsExec or WMI, followed by credential harvesting with tools like Mimikatz or LSASS memory access, followed by data staging and exfiltration, followed by ransomware deployment.
Each step generates specific log events. A correlation rule that fires when process creation logs show reconnaissance commands from a user account that authenticated for the first time from an external IP within the preceding 24 hours will catch this chain far earlier than a rule that looks for encryption activity.
Write correlation rules in terms of sequences and time windows. Most SIEM platforms support this through subsearches, join operations, or dedicated sequence detection features. Splunk uses subsearches and the transaction command. Elastic SIEM supports sequence rules natively in EQL (Event Query Language). Microsoft Sentinel uses KQL with let statements to build multi-step logic.
Baseline and Deviation Analysis
Correlation rules against known-bad patterns catch known attack techniques. Baseline deviation analysis catches unknown or novel techniques by identifying behavior that deviates from established norms. This is how the repurposed Hive implant was caught in environments where signature detection failed: the beaconing interval and the process tree were anomalous compared to that host's historical baseline, even though no specific signature matched.
Establish baselines for outbound connection counts per host, authentication event counts per account, process creation rates per system, and DNS query volumes per resolver. Use statistical methods like mean plus three standard deviations or interquartile range calculations to define normal bounds. Deviations beyond those bounds warrant investigation.
Log Analysis Threat Detection Checklist
Use the following checklist to assess and improve your current log analysis posture. This is organized around the four areas where most detection gaps occur.
Collection and Coverage
- Windows process creation logging (Event ID 4688) is enabled with command-line argument capture on all endpoints and servers.
- DNS query logging is active on all internal resolvers and logs are forwarded to the SIEM.
- Proxy or web gateway logs capture full request metadata including user-agent, destination URL, bytes transferred, and response code.
- Authentication logs from Active Directory, cloud identity providers, and VPN are ingested into a single platform where they can be correlated.
- Firewall logs capture both allowed and denied traffic, and NetFlow data is collected from core network devices.
- Cloud provider audit logs (CloudTrail, Azure Activity, GCP Audit) are enabled for all accounts and forwarded to centralized storage.
- Log retention policy meets both compliance requirements and investigation needs, with a minimum of 90 days hot storage and 12 months cold storage.
Detection Logic
- Correlation rules are written around multi-stage attack chains, not individual events in isolation.
- Rules exist specifically for ransomware precursor activity: reconnaissance commands, lateral movement tools, LSASS access attempts, and large outbound data transfers.
- Detection logic covers privilege escalation patterns, including new service registrations outside change windows and unexpected token manipulation events.
- DNS-based detection rules flag NXDomain spikes, high query volumes to single domains, and abnormally long query strings.
- Outbound connection rules flag periodic connections with consistent intervals and payload sizes from non-server endpoints.
- Authentication rules detect impossible travel, off-hours access from new devices, and sequential authentication failures across multiple accounts.
Operational Process
- Log alerts route to a queue that is reviewed on a defined schedule, with SLA targets for initial triage based on severity.
- Analysts have documented runbooks for the most common alert types that define investigation steps, escalation criteria, and containment actions.
- Threat intelligence feeds are integrated with the SIEM to enrich log events with known-bad IP addresses, domains, and file hashes.
- Regular threat hunting sessions use log data proactively to search for indicators of compromise outside the alert queue.
Validation and Tuning
- Detection rules are tested against simulated attack data on a quarterly basis to verify they fire as expected.
- False positive rates are tracked per rule and rules exceeding an acceptable threshold are tuned or retired.
- New threat intelligence is reviewed for log-based detection opportunities and translated into rules within a defined timeframe.
- Post-incident reviews include a log analysis component to identify what evidence was present, when it appeared, and whether detection rules should have fired.
Real-World Scenarios and How Logs Expose Them
Detecting a Hive-Style C2 Implant
The modified Hive implant circulating in criminal markets communicates over HTTPS with certificate pinning and jitter-based beaconing intervals. Signature detection often misses it because the traffic looks like standard HTTPS. Detection through logs focuses on three artifacts: the process initiating the connection is not a browser or expected application, the connection interval has low variance over time, and the destination IP has no prior connection history from that host.
In practice, this means correlating proxy logs (process name and destination) with NetFlow data (connection interval and byte count consistency) and threat intelligence enrichment (IP reputation for the destination). A Splunk query that joins proxy logs by source host and destination IP, calculates the standard deviation of connection intervals, and filters for low-variance results from non-browser processes will surface this activity.
Ransomware Precursor Lateral Movement
Before ransomware executes, attackers move laterally using stolen credentials and legitimate administrative tools. The log signature includes: Windows Event ID 4648 (explicit credential use) on multiple target systems in sequence, Event ID 4688 showing cmd.exe or PowerShell spawned by services.exe or svchost.exe (indicative of WMI or PsExec execution), and Event ID 4624 logon type 3 (network logon) across systems that the source account does not normally access.
A timeline-based correlation that shows the same account authenticating to five or more systems within a 30-minute window, combined with process creation events showing administrative utilities, should trigger a high-priority alert and immediate investigation.
Compromised Camera Infrastructure Access
The active market for access to compromised surveillance cameras means that internal hosts connecting to external camera management endpoints are a realistic threat scenario. Firewall and proxy logs showing internal workstations or servers making HTTP or RTSP connections to external IP ranges associated with camera vendors, particularly on ports 554, 8080, or 37777, merit investigation. Correlate those connection logs with process creation logs on the source host to determine what application initiated the connection.
Common Implementation Pitfalls
Logging Without Normalizing
Different log sources use different field names, timestamps, and formats for the same information. A Windows authentication event stores the username in the SubjectUserName field. A Linux PAM authentication event stores it in the user field. A VPN log might store it in the username field. Correlation rules that try to join these sources fail silently when field names do not match, producing no results rather than an error. Invest time in log normalization before building correlation logic. Use a Common Information Model (CIM) or a custom normalization layer to map source-specific fields to consistent names.
Treating Alert Volume as a Success Metric
A SIEM that fires 500 alerts per day does not indicate a healthy detection program. It indicates a tuning problem. Analysts who face hundreds of alerts daily develop alert fatigue and begin dismissing events without proper investigation. Prioritize alert quality over quantity. Tune rules aggressively to reduce false positives. Use risk scoring to aggregate low-confidence signals before surfacing them as alerts. A high-confidence alert that fires 10 times per day and represents real threats is more valuable than 500 noisy alerts of which two are real.
Ignoring Log Integrity
Attackers who gain sufficient access attempt to clear or modify logs to cover their tracks. Windows Event ID 1102 (audit log cleared) and 4719 (audit policy changed) are critical events that should trigger immediate alerts. Send logs to an immutable destination, a write-once S3 bucket, a syslog server that the compromised host cannot reach back to, or a SIEM with tamper-proof storage, as part of your collection architecture. Detecting that logs were cleared is only useful if a copy already exists off the compromised system.
Static Rules Against Dynamic Threats
Attack techniques evolve faster than most teams update their detection rules. The PhantomRPC privilege escalation technique and the modified Hive implant are recent examples of techniques that pre-date corresponding SIEM rules in many environments. Establish a process for converting threat intelligence into detection logic. When a new technique is reported, review it for log artifacts, write or update rules to detect those artifacts, and test the rules before deploying them to production. This process should take days, not months.
Skipping the Human Review Layer
Automated correlation and alerting handles high-volume pattern matching efficiently. It handles novel, low-and-slow attacks poorly. Scheduled threat hunting sessions where analysts review raw log data without relying on pre-defined alerts are essential for catching what automation misses. A weekly review of DNS query logs for unusual domain patterns, outbound connection logs for new external destinations, and authentication logs for off-hours access provides a human layer of detection that complements automated rules.
Building Toward Continuous Improvement
Log analysis for threat detection is not a project with a completion date. Attackers continuously adapt, new log sources become relevant as environments evolve, and detection logic that worked last year may miss techniques that are active today. The teams that detect threats early share a consistent characteristic: they treat log analysis as an ongoing operational discipline with regular review cycles, not a set-and-forget SIEM deployment.
Start with coverage gaps. Audit which log sources you collect, identify which critical sources are missing, and prioritize getting those into your aggregation platform. Then move to detection logic, reviewing your correlation rules against current threat intelligence and updating them where gaps exist. Then address operational process, making sure alerts route to humans who act on them within defined timeframes. Revisit each layer on a regular schedule, and use post-incident reviews to drive specific improvements rather than general intentions.
The logs are generating evidence of attacks happening right now. The question is whether your analysis capability is keeping pace with the threat actors using them.
