The Problem With Waiting for Obvious Signals
Security operations teams receive a consistent message from vendor marketing: modern SIEM platforms and log aggregation tools will surface threats before damage occurs. The reality inside most organizations looks different. The Russian global webmail espionage campaign highlighted in recent threat intelligence reporting is a clear example of what happens when adversaries operate within the boundaries of what logging configurations treat as acceptable behavior. Authentication events succeeded. Session durations fell within normal ranges. Exfiltration moved slowly enough to avoid volumetric thresholds. The logs captured everything. Detection happened late because the analysis framework was built around signatures rather than behavioral context.
This is the central challenge for cybersecurity professionals and IT administrators managing log analysis programs today: the data is almost always present. The gap is in how organizations decide what questions to ask of that data, at what frequency, and against which baselines. This article walks through a phased approach to building log analysis infrastructure that supports genuine threat detection, grounded in the kinds of campaigns that have been active through mid-2026.
What the Current Threat Landscape Demands From Your Logs
The ESET Threat Report for H1 2026 and the AI Security Report 2026 both point toward a consistent pattern: attackers are targeting identity infrastructure, cloud-hosted communication tools, and AI-adjacent platforms with increasing sophistication. Phishing campaigns targeting AI solutions providers, documented in early August 2026, used credential harvesting techniques designed specifically to blend into the log signatures that security tools are tuned to ignore. The passkey attack surface introduced by novel authentication bypass techniques adds another layer to this challenge, because organizations that migrated toward passwordless authentication reduced their reliance on password-based log signals without fully instrumenting the new authentication flows.
The implication for log analysis is direct. Your detection logic needs to evolve alongside the attack surface. Logging NTLM failures while attackers are exploiting passkey relay paths produces a dataset that looks clean while the compromise proceeds.
Foundational Log Sources That Most Programs Underinstrument
Before addressing detection logic, it is worth being direct about which log sources tend to be misconfigured or underweighted in real deployments.
Authentication and Identity Logs
Authentication logs from identity providers, directory services, and SSO platforms carry the highest signal density for most attack patterns in current campaigns. The specific fields that matter most are often not enabled by default. Token issuance logs, conditional access evaluation outcomes, device compliance states at the time of authentication, and MFA method used are all fields that distinguish a legitimate session from an attacker operating with stolen credentials. Organizations that log only success and failure events miss the contextual layer that makes behavioral analysis possible.
For environments using cloud identity platforms, ensure that sign-in logs include the full risk evaluation output from the identity provider, not just the final access decision. An authentication that succeeded after a risk evaluation returned a medium score is a different event from a clean low-risk success, and treating them identically in your SIEM creates blind spots that adversaries running slow-burn espionage campaigns will operate within comfortably.
Email Platform Telemetry
The webmail espionage pattern observed in recent campaigns exploits gaps in email platform logging that are common across both on-premises and cloud-hosted deployments. Mail forwarding rule creation, delegate access grants, and inbox filter modifications are high-fidelity indicators of account compromise in an espionage context. These events generate logs in most platforms but are rarely included in active detection rules because they fall outside the authentication-focused monitoring that most SOC teams prioritize.
Pull email administrator audit logs into your SIEM and build detection logic around forwarding rule creation, particularly rules that forward to external domains or that target mail categories like finance, legal, or executive correspondence. A single rule creation event is worth investigating. Multiple rule creation events across several accounts in a short window is an incident.
DNS Query Logs
DNS remains one of the most reliable data sources for detecting command and control activity, staged exfiltration, and newly registered domain use, and it remains underlogged in many enterprise environments. Recursive resolver logs, when fed into a SIEM with appropriate enrichment, surface patterns that are invisible in network flow data alone. High-frequency queries to a domain registered within the past 30 days, queries following a consistent timing pattern that suggests automated beaconing, and subdomains with high entropy in their labels are all detectable at the DNS layer before any payload inspection occurs.
The zipdump.py metadata encoding technique documented in recent threat intelligence highlights how attackers embed data in archive metadata to evade content inspection. DNS-based detection paths remain effective even when payload inspection fails, because the communication infrastructure still needs name resolution.
Building Detection Logic That Reflects How Campaigns Actually Operate
Signature-based detection handles known-bad with reasonable reliability. The problem is that sophisticated campaigns from actors operating in the espionage space, and increasingly from financially motivated groups with access to enterprise-grade tooling, are designed to avoid triggering signature libraries. Behavioral detection logic requires different construction.
Establish Honest Baselines
A behavioral detection rule is only as useful as the baseline it measures against. For authentication, baseline by user, by device, by network segment, and by time of day. A login from a known device on a known network during business hours for a user with consistent working patterns has a different risk profile than a login that matches the user account but diverges from all other parameters. Most organizations baseline at the aggregate level, which means individual anomalies disappear into the noise of the overall population distribution.
Spend time this week reviewing the baseline configurations in your SIEM or UEBA platform. Confirm that baselines are computed at a meaningful granularity, not just per-account averages that mask the behavioral context that makes outliers detectable.
Chain Events Across Log Sources
Individual log events are low-signal in isolation. The authentication success followed by the email forwarding rule creation followed by the large attachment download three days later is a coherent sequence that maps to an espionage pattern. Detecting each event individually means each one clears the threshold for investigation on its own, and the campaign continues. Chaining events across log sources into a temporal narrative is where serious threat detection happens.
Build correlation rules that look for sequences across a defined time window. An authentication from an unfamiliar location that is followed within 48 hours by a forwarding rule creation and within 72 hours by bulk mail access should produce a high-severity alert regardless of whether any individual event would have done so. This is not a complex rule from a logic standpoint, but it requires that all three log sources are normalized into a common schema in your SIEM and that correlation windows are configured to span days rather than minutes.
Prioritize Rare Events Over High-Volume Events
High-volume log sources produce alert fatigue when detection logic is not carefully scoped. Failed authentication events are high-volume and generate alerts constantly. A service account that has never previously authenticated to an external API making its first such connection is a low-volume event that carries substantially more signal. Shift analyst attention toward rare-but-meaningful events by building detection rules that count distinct behaviors rather than total occurrences.
Review your current alert volume and calculate what percentage of alerts come from high-frequency, low-context rules. In many SOC environments this number exceeds 70 percent. Reducing it requires both tuning existing rules and creating new ones that target behavioral rarity.
Today: Three Actions That Improve Coverage Immediately
If you are reading this with a live environment to manage, there are three log analysis improvements worth implementing before the end of the day.
- Enable verbose authentication logging in your identity platform. For Azure AD, Okta, or equivalent platforms, confirm that sign-in logs include risk scores, MFA method details, and device compliance status. If these fields are absent from your current log schema, they are absent from your detection coverage.
- Create a saved search or alert for email forwarding rule creation events. Pull Exchange Online management logs or equivalent into your SIEM if they are not already there. Build an alert that fires when any forwarding rule is created that routes mail to an external domain. Set the severity high and route it to a human reviewer rather than an automated response queue.
- Review DNS logging coverage. Confirm that your recursive resolvers are forwarding query logs to your SIEM. If they are not, this is a same-day configuration change in most environments that substantially expands your detection surface for C2 activity.
This Week: Structured Review of Log Retention and Coverage Gaps
Within the next five to seven days, conduct a structured audit of your log coverage against the attack patterns documented in recent threat intelligence reporting. Map each phase of the campaigns described in the July and August 2026 threat intelligence reports to a specific log source that would generate evidence of that activity in your environment. Where the mapping fails, you have a coverage gap.
Common gaps that emerge from this exercise include cloud workload logs that are collected but not normalized into your SIEM schema, API gateway logs that capture traffic volume but not request content or header fields, and endpoint detection telemetry that is stored separately from your central log platform and therefore excluded from correlation rules.
Retention is a separate issue from collection. Espionage campaigns operate over months. If your authentication log retention is 30 days and an investigation requires reconstructing activity from 90 days ago, the evidence is gone. Review retention periods against the dwell times documented in current threat intelligence. The 2026 reporting consistently shows dwell times for sophisticated actors measured in weeks to months, not days.
This Quarter: Building a Log Analysis Program That Supports Proactive Hunting
Reactive detection, waiting for a rule to fire and then investigating, handles the cases that fit your existing detection logic. Proactive threat hunting using log data handles the cases that do not. Over the next quarter, build the infrastructure that supports both.
Structured Threat Hunting With Log Data
Threat hunting with logs requires queryable access to normalized data across multiple sources over an extended time horizon. If your SIEM costs make long-retention hot storage impractical, evaluate tiered storage approaches where recent data lives in a fast-query store and older data is queryable from cold storage with acceptable latency for non-urgent hunts.
Define a quarterly hunting calendar tied to current threat intelligence. When reporting describes a specific technique, such as the metadata encoding approaches in recent ZIP-based malware analysis, run a retrospective hunt against your DNS, proxy, and endpoint logs to determine whether the technique has been observed in your environment. This transforms threat intelligence from informational reading material into an actionable input to your security operations program.
Instrument the Attack Surface That Current Campaigns Target
The phishing campaigns targeting AI solutions providers documented in August 2026 represent an expansion of the attack surface that many organizations have not fully instrumented. If your environment includes AI-integrated platforms, API endpoints exposed to AI agents, or cloud services accessed by automated workflows, these surfaces generate log data that requires specific analysis approaches distinct from traditional user-behavior baselines.
Machine-to-machine authentication patterns, API token usage at scale, and automated workflow execution logs need their own baselines and detection logic. Applying user-behavior rules to service account and API-level activity produces both false positives and missed detections. Build dedicated log analysis pipelines for these surfaces as they become part of your production environment.
Validate Detection Coverage With Simulated Attack Paths
Detection rules that have never been triggered by a real or simulated attack may have configuration errors, schema mismatches, or threshold settings that prevent them from firing. Quarterly validation exercises using purple team techniques or automated adversary simulation tools verify that your log collection, normalization, correlation, and alerting pipeline functions end-to-end for the techniques you are trying to detect.
Run simulations that specifically target the attack chains documented in current threat intelligence. If the ESET H1 2026 report describes a specific credential access technique that is prevalent in your sector, that technique should appear in your simulation plan and your log analysis coverage should be verified against it before the next quarter's reporting cycle.
Operational Hygiene That Determines Whether Analysis Actually Works
The effectiveness of log analysis for threat detection degrades steadily when operational hygiene around the logging infrastructure itself is neglected. Clock synchronization across log sources is a prerequisite for temporal correlation. Log sources with time skew larger than a few seconds produce correlation failures that look like gaps in attacker activity when they are actually gaps in data alignment. Audit NTP configuration across all log-producing systems and confirm that your SIEM ingestion pipeline handles timezone normalization consistently.
Log integrity also matters for investigation purposes. Logs stored without integrity controls are susceptible to tampering by attackers who have achieved sufficient access to your environment. Forward-write log storage, write-once destinations, or cryptographic chaining of log records provides the evidentiary integrity that forensic investigation requires. This is particularly relevant in environments where insider threat or advanced persistent access is a plausible scenario.
Finally, maintain documentation of what each log source captures and what it does not. A proxy log that records URL paths but strips query strings captures different information than one that logs complete request URIs. An authentication log that records the requesting IP but not the application that initiated the authentication flow tells a partial story. Understanding the completeness of each data source prevents investigators from drawing conclusions from absence of evidence when absence is an artifact of logging configuration rather than absence of activity.
Closing Perspective
The espionage campaign patterns, the AI-targeted phishing activity, and the novel authentication attack surfaces documented in 2026 threat intelligence reporting share a common characteristic: they are detectable in log data when analysis programs are built to look for them. The data exists in most environments. The gap is in detection logic, coverage completeness, retention depth, and the operational discipline to run proactive analysis rather than waiting for threshold-based alerts to fire.
Building a log analysis program that closes this gap is not a single project. It is an ongoing operational discipline that requires regular review against current threat intelligence, structured coverage validation, and investment in the analyst capability to ask the right questions of the data that is already being collected.
