MITRE ATT&CK T1678 Delay Execution Guide

MITRE ATT&CK T1678 Delay Execution covers malware and intruders that wait, on purpose, so that automated analysis times out and defenders stop looking before the real activity starts. The wait can be a programmatic sleep, a loop of harmless commands such as ping, a flood of API calls, a scheduled job set for later, or a check against a date weeks in the future. ATT&CK v20 lists the technique under the Stealth tactic for Linux, macOS and Windows, and links it to ransomware, espionage tooling and supply chain malware. This guide explains the variants in defensive terms, the telemetry and analytics that catch them, how to set up sandboxing and alert correlation so a delay does not win, and how to measure it. It is for detection engineers, malware analysts and SOC leads.

Key takeaways

A delay is a bet on your time windows. Sandboxes that run a sample for a few minutes and correlation rules that look back an hour are exactly what T1678 is designed to outlast.
The delay itself is often visible. Long ping loops to localhost, timeout or sleep calls in a launcher command line, and scripts with no I/O for long periods are detectable on the host.
Longer windows beat cleverer rules. Correlating by process tree and host across hours or days catches staged activity that per-event rules miss.
Sandbox verdicts need a time caveat. A clean result after a short run means "nothing seen in that window", not "benign"; combine dynamic analysis with static and reputation signals.
Dormancy is the long form of the same idea. Implants that beacon rarely or activate after a future date require hunting and periodic re-review, not just initial scanning.

What T1678 describes

MITRE describes Delay Execution as adversaries using "time-based methods to evade detection and analysis", exploiting system clocks, delays or timing mechanisms to obscure activity and blend in, either inside sandboxes or natively on hosts. The technique sits next to T1497 Virtualization/Sandbox Evasion, whose sub-technique T1497.003 Time Based Checks covers checking for signs of an analysis environment through time. T1678 is broader: the delay does not have to involve detecting a sandbox at all.

Variant	How it works (defensive summary)	Example recorded by MITRE or the cited analysis
Programmatic sleep	Calls such as `Sleep` or `NtDelayExecution` on Windows, `sleep` or `nanosleep` on Unix-like systems, before or between stages	DynoWiper paused five seconds between attack phases; GlassWorm used a 15 minute timeout
Benign command loops	Repeating harmless commands, most often `ping` with a large count, or `timeout`, to burn time	ATT&CK cites ping loops used to delay ransomware and botnet payloads and to exceed analysis time limits; Mustang Panda chained a 70 count ping to a payload launch
API hammering	Large numbers of pointless API calls that delay the payload and flood sandbox logs	ATT&CK describes calls to Native API functions that delay execution and can overload analysis environments with junk data, citing TrickBot and Nymaim samples
Scheduled or deferred execution	Using the OS scheduler, background forking or persistence scripts to run later	TeamPCP Cloud Stealer's persistence script slept five minutes; Shai-Hulud forked into a background process before larger payloads
Future date activation	Waiting until a stored date passes before acting	In the supply chain attack ATT&CK tracks as C0057, the compromised software picked a random date one to four weeks ahead and checked it against the local clock
Long beacon intervals and jitter	Slow or randomised command and control check-ins that look like background noise	RustyWater used random sleep intervals between C2 communications; APT38 lengthened beacon intervals after network failures

See the ATT&CK Stealth and Defense Impairment Tactics Guide for the wider tactic, and the Defence Evasion Techniques Guide for related techniques.

Detection analytics

MITRE's detection strategy for T1678 (DET0372 in ATT&CK v20) gives one analytic per platform. The table summarises them with the log sources MITRE names and the tuning inputs it calls out.

Platform	What to look for	Log sources	Tuning inputs
Windows	Short-lived processes using sleep or delay APIs, launched by script hosts such as wscript or PowerShell with little user interaction	Sysmon Event ID 1 (process creation) and Event ID 7 (image loaded)	Delay duration; expected parent and child pairs; which sleep APIs to match
Linux	Scripts or binaries repeatedly calling `sleep`, `ping` or `nanosleep` in short execution chains with no user or system interaction, often from cron or stagers	auditd SYSCALL (execve, nanosleep with no stdout or stderr I/O) and PROCTITLE	Command line patterns; time between syscalls; root or service user context
macOS	AppleScript, bash or launchd jobs that call `sleep` or AppleScript `delay`, then stage follow-on commands	Unified log (launchd or osascript spawning processes with delay commands)	Script type; user or daemon context; delay threshold

Rules that work in practice

Large ping counts: ping to 127.0.0.1 or a public resolver with a count well above normal troubleshooting use, launched by cmd, PowerShell, a script host or an Office application, followed by another command in the same line (&& or ;). Mustang Panda's recorded pattern chained a 70 count ping to a payload launch.
Delay commands in launchers: timeout /t, Start-Sleep, sleep or choice /t inside command lines spawned by Office, browsers, archive tools or remote management agents.
Silent long-running children: a script process that runs for minutes with no network, file or registry activity, then suddenly writes an executable or opens a connection.
Delayed first network contact: a new binary whose first outbound connection happens long after it started, measured from EDR process start and network events.
Beacon regularity: network analytics that score connections for periodic timing, with jitter tolerance, across days rather than hours.
Scheduled job creation with a future start: new scheduled tasks, cron entries, launchd items or systemd timers created by unusual parents, especially with one-off start times. See the T1053 Scheduled Task/Job Defensive Guide.

Sysmon image load logging (Event ID 7) is off by default and Microsoft warns that logging every image load is very noisy, so scope it to script hosts and unusual paths rather than enabling it everywhere.

Making sandboxes and correlation outlast the delay

T1678 targets analysis windows more than any single control, so the fix is mostly configuration of time.

Control point	Typical gap	What to change
Email and web sandbox	Fixed short run time; verdict treated as final	Use the longest practical run time for high-risk file types, enable any sleep-skipping or time acceleration your sandbox offers, and treat "no behaviour observed" as inconclusive
Manual malware analysis	Analyst runs a sample once and moves on	Re-run with extended time, patched delay calls or a debugger, and pair with static analysis of strings and imports
SIEM correlation	Rules join events within minutes	Add process-tree and host-scoped correlations over 24 hours or more for staged activity
EDR alert grouping	Early benign-looking stage auto-closed before later stage fires	Keep the incident open and linked by process GUID or lineage; do not auto-close parent alerts too early
Incident eradication	Declared clean after a quiet period	Hunt for dormant implants and scheduled jobs before closure; NIMBUS MANTICORE is recorded reactivating backdoors after eradication attempts

See the Malware Sandbox Guide for sandbox deployment and configuration.

Where identity fits

Delays are common in malware that steals machine credentials. MITRE links T1678 to TeamPCP Cloud Stealer and Shai-Hulud, both aimed at developer and cloud tokens, and the delay buys time for those credentials to be used before the infection is noticed. Treat a confirmed delayed-execution sample on a developer workstation or CI runner as a credential exposure: rotate the tokens, keys and publishing credentials that host could reach, rather than waiting to see whether the payload ran. See the Shai-Hulud npm Worm Guide and the TeamPCP Threat Actor Profile Guide.

How to implement

Collect the right telemetry. Process creation with full command line on all platforms (Sysmon Event ID 1, Security 4688 or EDR), auditd execve on Linux servers, unified log forwarding on macOS, and scoped Sysmon Event ID 7 for script hosts.
Baseline legitimate delays. Installers, backup jobs and admin scripts use sleeps and timeouts. List them by parent process, path and signer before writing alerts.
Deploy command line rules in audit mode. Start with large ping counts and delay commands from Office, browsers and script hosts. Review two weeks of hits, then promote to alerting.
Extend correlation windows. Add at least one detection that links a suspicious launcher to any later executable write or outbound connection from the same process tree within 24 hours (our suggested starting window).
Tune sandboxes. Review run time and anti-evasion settings with your sandbox provider's documentation, and change triage playbooks so a short clean run is never the only evidence.
Test. In an authorised lab, run benign test scripts that wait before writing a marker file or making a connection, and confirm the sandbox, EDR and SIEM all record the later stage.
Roll back. Keep new rules in a separate rule set or tag so noisy ones can be disabled without touching established detections.

Decision guidance

Prevention or detection: there is no way to prevent software from waiting. Invest in execution prevention for the stage after the delay (application control, script controls) and in detection of the delay pattern itself.
Sandbox time versus throughput: longer runs reduce throughput. Reserve extended runs for high-risk types (scripts, macros, archives, installers) and for files from new senders or domains.
Small organisations: rely on your email and EDR providers' analysis, turn on process command line logging, and add one or two simple rules for long ping and timeout commands.
Large organisations: run long-window correlations, beacon analytics on network data and scheduled hunts for dormant persistence.

Detection and measurement

Command line coverage: percentage of endpoints and servers sending process creation events with full command lines.
Long-window rules: number of production detections with a correlation window of 24 hours or more.
Sandbox inconclusive rate: share of sandbox runs that end with no behaviour observed, and how many of those are later found malicious.
Test catch rate: share of authorised delayed-stage tests where the later stage was detected and linked to the first.
Dormant persistence findings: scheduled jobs or implants found by periodic hunts that no alert had raised.

Framework mapping

Framework	Item	Relevance
MITRE ATT&CK	T1678 Delay Execution; related T1497.003 Time Based Checks and T1053 Scheduled Task/Job	The technique and its closest neighbours
MITRE D3FEND	D3-DA Dynamic Analysis; D3-PSA Process Spawn Analysis; D3-SEA Script Execution Analysis	Sandbox analysis, parent and child process analytics, script monitoring
NIST SP 800-53 Rev. 5	SI-3 Malicious Code Protection; SI-4 System Monitoring; AU-12 Audit Record Generation	Analysis, monitoring and logging that support detection
NIST CSF 2.0	DE.CM-09; DE.AE-02	Monitoring runtime environments; analysing adverse events

Common failure patterns

Clean sandbox treated as proof: a file released because a short dynamic run showed nothing, when the sample was simply still waiting.
One-time vetting: trusting a package or extension because it looked harmless when first installed; the GlassWorm Campaign 2025 page describes extensions that turned malicious through later updates.
Short correlation windows: rules that only join events minutes apart, so a 90 minute pause splits one attack into unrelated low-severity alerts.
Allowlisting all ping and timeout use: excluding these commands to cut noise, which removes the most visible delay signal.
Closing incidents too quickly: declaring a host clean after a quiet day without hunting for scheduled jobs and dormant implants.

Practitioner checklist

Collect process creation with full command lines on every platform.
Alert on large ping counts and delay commands launched by Office, browsers and script hosts.
Baseline and document legitimate sleeps in installers and admin scripts.
Add process-tree correlations with windows of 24 hours or more.
Treat short clean sandbox runs as inconclusive in triage playbooks.
Extend sandbox run times for scripts, macros, archives and installers.
Hunt for new scheduled tasks, cron jobs, launchd items and systemd timers with one-off future starts.
Rotate credentials reachable from any developer or CI host with a confirmed delayed-execution sample.

MITRE ATT&CK T1678 Delay Execution: Detecting Evasion