What are the signs that a zero-day attack may be underway?

The clearest signs are behavioral rather than file based: unusual process execution, suspicious outbound connections, and unauthorized access attempts. Teams should also watch for privilege escalation, unexpected persistence, and lateral movement after an initial foothold. Because zero-days often bypass traditional defenses, these operational anomalies are usually more useful than waiting for a known indicator.

What operators should look for before a zero-day becomes obvious

Zero-day activity rarely announces itself with a neat signature. The practical clue is a cluster of behavior that does not fit the environment, especially when it appears across endpoint, identity, and network telemetry at the same time. That can include anomalous process trees, unexpected child processes, unusual service creation, unexplained outbound traffic, or repeated authentication failures that precede successful access. The issue is not any single alert, but the way several low-confidence anomalies line up.

For defenders, the important distinction is between noise and pattern. A single odd execution may be benign, but a sequence that shows discovery, privilege gain, and movement between hosts deserves immediate attention. In practice, many security teams recognise zero-day impact only after the attacker has already combined several weak signals into a working intrusion path, rather than from one definitive indicator.

How zero-day compromise tends to appear in live telemetry

Because the exploit itself is unknown, teams usually detect the aftermath of exploitation instead of the exploit code. That means investigation should focus on what changed: new processes running from unusual paths, memory-only execution, abnormal parent-child process relationships, and fresh remote connections to infrastructure that has no business purpose. If the attack reaches further, the same incident often shows signs of credential abuse, service tampering, or broadening access that cannot be explained by normal administration.

A useful way to read the evidence is as a chain. First, something executes that should not have executed. Next, the host starts communicating in a way it has not before. Then the adversary tries to stay resident or expand access. That sequence is why zero-day hunts depend so heavily on correlation across logs rather than a single endpoint event. The most reliable evidence is often the combination of process, network, and authentication anomalies, not one perfect indicator.

Watch for unusual process ancestry and command-line patterns that do not match normal software behavior.
Correlate outbound connections with new binaries, new services, or recent configuration changes.
Check for privilege changes, unexpected token use, or access that occurs outside normal operational windows.
Look for lateral movement indicators such as remote service creation, admin shares, or repeated host-to-host access.

MITRE ATT&CK is useful here because it helps teams describe the behavior they can actually observe, especially when the initial exploit is still unknown. CISA cyber threat advisories can also help validate whether the observed pattern matches active campaign tradecraft without assuming the exploit mechanism itself.

Where this guidance breaks down is in highly noisy environments with poor baselines or limited telemetry, because the same pattern can be buried under normal administrative activity.

Why some zero-day indicators are easy to miss

Tighter monitoring often increases false positives, so organisations have to balance faster detection against alert overload. That tradeoff matters because zero-day activity can look like legitimate troubleshooting, software deployment, or a one-off operational anomaly until it repeats or expands. The biggest blind spot is assuming that a lack of known malware hashes means a lack of compromise.

There is no consensus that any one log source is sufficient. Some teams lean too heavily on endpoint alerts, while others over-trust perimeter logs that do not show what happened after the first foothold. The better approach is to treat zero-day suspicion as a multi-signal problem and to accept that the earliest proof may come from the environment’s behavior, not from the exploit artifact itself.

That is also why identity and access telemetry can matter even when the initial issue is not an identity problem. If an exploit is used to jump from code execution to privilege escalation, the access pattern often becomes the clearest proof that the event is moving from anomaly to incident. The practical warning sign is not just that something ran, but that it began to act like an operator.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
MITRE ATT&CK	T1059 — Command and Scripting Interpreter	Zero-day activity often first appears as unusual process execution.
	T1105 — Ingress Tool Transfer	Unexpected outbound connections can signal payload delivery or follow-on staging.
	T1021 — Remote Services	Lateral movement after initial foothold is a common zero-day aftermath pattern.
Recommendation — Map suspicious execution to T1059 and investigate the process chain for post-exploitation activity. Correlate outbound transfers to T1105 and isolate hosts that fetch unknown tools. Hunt remote access activity under T1021 when one host begins reaching others abnormally.
CIS Controls v8	8 — Audit Log Management	Detecting zero-day behavior depends on correlating endpoint, network, and identity logs.
Recommendation — Centralise and correlate logs so weak signals can be joined into a credible intrusion sequence.

Practitioner Guidance

What to prioritise: Treat unexplained process execution, unusual network egress, and access anomalies as a single investigative set rather than three separate tickets. The priority is to determine whether the activity is isolated noise or the beginning of post-exploitation behavior.

What to verify: Confirm whether the host shows a believable chain of execution, whether the outbound destination has a business justification, and whether recent authentication or privilege changes align with known admin activity. If any one of those checks fails, escalation should move from suspicion to incident handling.

Common mistake: Teams often wait for a known signature or malware family match before acting, which is the wrong threshold for a zero-day suspicion. A lack of known indicator is not evidence of safety when the behavior already shows compromise patterns.

Practitioner takeaway: The most useful question is not “what exploit is this?” but “does the environment now behave like an attacker is already inside?”