Detecting and Mitigating Delay Execution (MITRE ATT&CK T1678)

Delay Execution (T1678) is a technique where adversaries use time to avoid detection and analysis. MITRE places it in the Stealth tactic and lists Linux, macOS and Windows as platforms.

How attackers use it

MITRE explains that adversaries exploit system clocks, delays and timing mechanisms to obscure malicious activity, blend in with benign behavior and avoid scrutiny. This can happen inside virtualization and sandbox environments or directly on a host.

The page lists several methods:

• Programmatic sleep commands. The malware simply waits before acting.
• Native scheduling. For example, Scheduled Task/Job (T1053).
• Benign commands used as delays. Loops or needless repetition of commands such as ping can hold execution back past the time limits of an automated analysis environment.
• API hammering. Many calls to Native API functions delay execution and may also overload analysis environments with junk data.

The delay can be very long. MITRE's examples include malware that picks a date one to four weeks in the future and sleeps until then, malware built with a timer that waited for a hard-coded date months away before beaconing, and implants that delay command and control beaconing to longer intervals after network failures.

The reasoning is simple. An automated sandbox gives a sample a few minutes. A sample that does nothing for a few minutes looks clean.

How to detect it

MITRE's detection strategy is multi-platform and works through correlation:

• Windows. Sleep and delay mechanisms, such as kernel32!Sleep and NTDLL APIs, in short-lived processes. Combine this with parent processes starting suspicious scripts, such as wscript or powershell, with little user interaction.
• Linux. Shell scripts or binaries that call repeated sleep or ping, or low-level calls such as nanosleep, in short-lived chains with no user or system interaction. MITRE notes this is often seen in malicious cron jobs and payload stagers.
• macOS. AppleScript, bash or launchd jobs that call delay functions with limited parent interaction and staged follow-on commands.

Because sleep and ping are normal, no single event is a verdict. The signal is the pattern: a delay, in an unattended process with an odd parent, followed by something else.

For long delays, behavior over weeks matters more than behavior over minutes. Beaconing that starts months after install is easier to catch with network baselining than with sandbox detonation.

How to reduce the risk

MITRE lists no formal mitigation. Practical steps:

• Do not rely only on short sandbox runs to approve a file. Extend analysis time, or combine it with static and behavioral analysis.
• Keep endpoint telemetry long enough to look back at when a delayed implant wakes up.
• Review scheduled tasks and cron jobs for entries nobody can explain.
• Alert on new outbound connections from processes that have been idle.

Check your own environment

• How long does your sandbox or detonation tool run each sample?
• Can your EDR show a process tree for a script that started a long time ago?
• Do you know which scheduled tasks and cron jobs exist on your servers?
• Do you retain network logs for at least several months?

Quick check

Sources

• MITRE ATT&CK, Delay Execution (T1678): https://attack.mitre.org/techniques/T1678