When the Infection Is Already Inside Before the Alert Fires
The recent Mini Shai-Hulud supply chain infections offer a sharp reminder of what happens when threat actors choose their entry point carefully. Rather than attacking perimeter defenses directly, this worm family propagated through trusted software distribution channels, meaning the initial execution happened in environments where the activity looked legitimate. By the time behavioral indicators surfaced in endpoint logs, lateral movement was already underway across multiple tenants in affected supply chains.
This is the pattern that makes log analysis so difficult in practice. The telemetry was there. Authentication events, process creation records, network connection logs, and file system changes all generated data. The gap was not a collection failure. The gap was interpretation under time pressure, across fragmented log sources, without a clear correlation model to connect the dots before the worm reached the next hop.
Ransomware attack frequency has climbed steadily into 2025 and shows no sign of reversing. The WSzero DDoS family, now in its fourth major version, exploited 21 vulnerabilities in its propagation chain. Supply chain compromise and multi-vector malware campaigns are no longer edge cases. They are the baseline threat model that log analysis pipelines need to be designed around.
What Logs Are Actually Available and What They Tell You
Before discussing correlation strategy, it helps to be precise about what each log source actually contains and where each one falls short on its own.
Windows Event Logs
Windows Event Logs remain the most complete source of host-level activity on most enterprise networks. Event ID 4624 records successful logon events and includes the logon type, source IP, and target account. Event ID 4625 records failed logons. Event ID 4688 records process creation when the relevant audit policy is enabled, and critically, it can include the full command line if that option is turned on in Group Policy.
The problem with Windows Event Logs in supply chain scenarios is that initial execution often comes from a process that has legitimate signing and reputation. A software updater spawning a child process looks normal until you examine what that child process does next. This is where parent-child process relationship analysis becomes essential. Event ID 4688 alone is not enough. You need to chain process creation events by parent PID across a time window to see execution trees that reveal post-exploitation behavior.
DNS Query Logs
DNS logs are underutilized in most environments. Every connection attempt that uses a hostname generates a DNS query, which means DNS logs provide a network-level view of what systems are trying to reach, even when the traffic itself is encrypted. Domain generation algorithm (DGA) activity, newly registered domains used for command and control, and internal DNS queries to unexpected resolvers all appear in DNS logs before firewall or proxy logs capture the connection.
For supply chain worm scenarios, DNS logs frequently show the first indicator of post-infection activity. The malware queries its C2 infrastructure within seconds to minutes of execution. If you are capturing DNS query logs from your internal resolvers and comparing queried domains against threat intelligence feeds in near-real-time, you can catch this before the exfiltration stage begins.
Proxy and Web Gateway Logs
Proxy logs capture HTTP and HTTPS requests including URL, user agent, response code, bytes transferred, and the authenticated identity of the requesting user or host. For threat detection, the most valuable fields are the user agent string, the response content-type versus the file extension in the URL, and the ratio of outbound to inbound bytes.
Unusual user agent strings are a reliable indicator when attackers use custom tooling that has not been profiled to mimic common browser behavior. Large outbound byte counts to newly observed external hosts following a software update event are the kind of chained anomaly that appears in proxy logs but requires correlation with other sources to interpret correctly.
Firewall and NetFlow Data
Firewall logs tell you what was allowed or blocked at the network boundary. NetFlow data tells you about traffic volume and connection patterns between internal hosts. Together, these sources are essential for detecting lateral movement, which appears as a sudden increase in east-west traffic between hosts that have no historical communication pattern.
The Linux vulnerability disclosed recently, which has been described as among the most severe in years, creates conditions where an attacker with initial access can move laterally through Linux hosts using techniques that generate minimal application-layer logging. In these cases, NetFlow becomes one of the primary detection mechanisms because the network behavior of scanning and connection attempts is visible even when the host-level audit trail is limited.
Building a Correlation Model That Catches Worm Behavior
Individual log sources generate alerts. Correlation generates detections that hold up under investigation. For supply chain and worm scenarios specifically, the correlation model needs to account for several behavioral patterns simultaneously.
Execution Chain Analysis
Start with the software update or installation event as the anchor. If your environment uses software deployment tools like SCCM, Intune, or a third-party patch management platform, those tools generate their own logs when packages are deployed. Correlate package deployment events with process creation events on the target host within a defined time window, typically five to fifteen minutes. Any child process spawned by the installer that subsequently initiates a network connection to an external host should generate an investigation queue entry automatically.
This is not a rule that will fire constantly in a well-managed environment. Software installers that reach out to external hosts after installation do so to activation endpoints or update check URLs that recur predictably. A process spawned by an installer that connects to a previously unobserved IP address in a hosting ASN with no prior organizational relationship is a different matter entirely.
Beaconing Detection
Command and control traffic from modern malware frequently uses beaconing, which means the infected host makes outbound connections at regular intervals. The interval may be randomized to avoid simple frequency detection, but the underlying pattern remains detectable through statistical analysis of connection timing.
In your SIEM, build a query that groups outbound connections by source host and destination IP, then calculates the standard deviation of the time intervals between connections. A low standard deviation over a period of hours indicates regular, automated communication. Combine this with the observation that the destination IP was first seen in your environment within the past 24 to 48 hours, and you have a high-confidence beaconing indicator.
Most commercial SIEMs support this kind of statistical detection natively. In Splunk, the streamstats command calculates running statistics across time-ordered events. In Microsoft Sentinel, KQL provides functions for time-series analysis. The implementation is straightforward once you define the query logic. The operational challenge is tuning the threshold so that legitimate heartbeat traffic from monitoring agents and cloud services does not flood the investigation queue.
Credential Anomalies Following Installation Events
Supply chain malware frequently harvests credentials from the initial host and uses them to authenticate to other systems in the environment. This produces a specific pattern in authentication logs: a user account that normally authenticates from a single workstation suddenly authenticates from a different internal host, at an unusual time, to a resource it has not accessed before.
Map user accounts to their typical source hosts using 30 days of authentication history. When an authentication event occurs from a source host that accounts for fewer than one percent of that user's historical logons, flag it. Weight the risk score higher if the authentication target is a server rather than a workstation, if it occurs outside business hours, and if it follows a software installation event on the source host within the preceding hour.
Log Retention and the Forensic Investigation Problem
Ransomware incidents frequently reveal that attackers spent days to weeks inside the environment before deploying their payload. Forensic investigations need log data that goes back far enough to reconstruct the full attack timeline. The standard recommendation of 90 days of retention for security-relevant logs is a minimum, not a target.
The practical challenge is storage cost. High-volume log sources like NetFlow, DNS, and proxy logs generate hundreds of gigabytes per day in enterprise environments. Tiered storage strategies that keep recent logs in hot storage for fast querying and older logs in cold storage for archival retrieval are a workable compromise. The important constraint is that cold storage logs must be retrievable within hours during an active incident, not days.
Define your retention requirements by log source based on how far back you need to look to understand a typical attack in your environment. Authentication logs and process creation logs should be retained for at least 180 days. Network flow data can often be retained in summarized form beyond 90 days, capturing five-minute aggregates rather than individual flows, which reduces storage volume while preserving enough detail for timeline reconstruction.
The Supply Chain Scenario in Practice: A Detection Walkthrough
Consider a specific scenario modeled on recent supply chain worm incidents. A software vendor's update package is compromised. The update deploys to 200 workstations across an enterprise environment over a six-hour window. The malware executes silently, establishes persistence through a scheduled task, and begins beaconing to its C2 infrastructure.
Here is what each log source captures and when.
At T+0, the software deployment platform logs show the package was pushed to 200 endpoints. This is normal and expected. At T+2 minutes, Windows Event Log 4688 on affected hosts shows the installer spawning a secondary process with an unfamiliar executable name located in a user-writable directory. This is the first anomalous indicator. At T+3 minutes, DNS logs show queries from affected hosts to a domain registered 11 days ago. At T+4 minutes, proxy logs show outbound HTTPS connections from the same hosts to an IP address in a cloud hosting provider. The user agent string is a version of Chrome that does not match the Chrome version installed on those workstations. At T+15 minutes, Windows Event Log 4698 shows a scheduled task creation on affected hosts. At T+45 minutes, Event Log 4624 shows the harvested credentials used to authenticate from one affected workstation to a file server, with logon type 3 (network logon).
A correlation rule that chains the installer event, the child process creation, and the DNS query to a new domain would fire at T+3 minutes. That is before lateral movement begins. The investigation queue entry generated at that point contains enough context for an analyst to confirm the indicator within minutes and initiate containment.
Without that correlation rule, the individual events each look insufficient to act on. A process spawned by an installer is common. A DNS query to an unfamiliar domain might be a false positive. A proxy connection with an unusual user agent might be an internal application. The detection happens only when the events are linked across time and source.
Tuning for the Long Tail of Evasion Techniques
Attackers who deploy supply chain malware do not use off-the-shelf tooling that signature-based detection catches on first contact. They use modified implants, legitimate system tools abused for malicious purposes, and communication protocols that blend with normal traffic. The Linux threat disclosed recently exploited a kernel-level vulnerability that allowed code execution in conditions where standard audit logging does not capture the event.
For defenders, this means behavioral detection rules must account for what happens after execution, not just the execution event itself. Living-off-the-land techniques that use built-in tools like PowerShell, WMI, certutil, and regsvr32 for malicious purposes generate Windows Event Log entries for each invocation. The individual events look like normal system administration. The sequence of events, specifically the combination of tools used within a short window, is the detection signal.
Build detection logic around sequences rather than individual events. A rule that fires on PowerShell execution alone generates too many false positives to be actionable. A rule that fires on PowerShell execution followed within five minutes by a scheduled task creation on the same host, where the task references an executable in a temp directory, is specific enough to investigate every time it fires.
Handling Encrypted Traffic
TLS inspection is not universally deployable, and attackers know it. For environments where you cannot inspect encrypted traffic, DNS and IP reputation analysis compensate for some of the visibility gap. Destination IPs with poor reputation, hosting characteristics associated with bulletproof providers, or ASNs with high rates of malicious activity serve as behavioral signals even when the payload is encrypted.
Certificate transparency logs provide another detection avenue. When attackers obtain TLS certificates for newly registered domains used in C2 infrastructure, those certificates appear in public CT logs within minutes of issuance. Subscribing to CT log feeds and cross-referencing newly issued certificates against your DNS query logs identifies C2 domains before they have been catalogued by threat intelligence feeds.
Operationalizing Log Analysis Across Shifts
Detection engineering builds the rules. Operations teams run them. The gap between what rules produce and what analysts actually investigate is where detections die quietly. Alert fatigue is a well-documented problem, but the solution is not fewer alerts. The solution is better alert prioritization and context enrichment that makes each alert self-explanatory enough to triage in under two minutes.
Every alert that goes to an analyst should include the source host, the affected user account, the specific events that triggered the correlation, a link to the relevant MITRE ATT&CK technique, and the similar alerts generated by the same host in the preceding 24 hours. Analysts who can see the full context immediately make better triage decisions faster, which means higher-priority alerts get investigated before the attack progresses to the next stage.
Document investigation runbooks for each detection rule. A runbook for the supply chain execution chain rule described above specifies which additional log sources to query, what questions to answer before escalating, what containment action to take if the alert is confirmed, and which team member owns the escalation path. Runbooks eliminate decision latency during incidents when cognitive load is highest.
Where to Focus First
If your log analysis program is still developing, prioritize in this order. First, ensure you are collecting Windows process creation logs with command line auditing enabled across all hosts. Second, configure your internal DNS resolvers to forward query logs to your SIEM. Third, build a baseline of normal outbound connection behavior by host and by user, and alert on deviations involving newly observed external destinations. Fourth, implement parent-child process relationship analysis for your top ten most commonly abused system executables.
These four capabilities, implemented consistently across your environment, provide detection coverage for the majority of post-exploitation techniques used in supply chain attacks, ransomware deployment chains, and worm propagation scenarios. They do not require advanced machine learning or expensive tooling. They require complete log collection, well-structured correlation rules, and analysts who know what the rules mean when they fire.
The supply chain threat landscape in 2025 is not getting simpler. Fresh worm variants, newly discovered kernel vulnerabilities, and increasingly sophisticated evasion techniques mean that log analysis programs built for yesterday's threat model will fall short. The organizations that detect and contain these attacks earliest share one characteristic: they treat log analysis as an active, continuously refined discipline rather than a compliance checkbox.
