T1678

Delay Execution

Defense Evasion Last updated:

This detection identifies adversary attempts to delay malicious execution using time-based evasion techniques including ping-loop delays, programmatic sleep commands, timeout utilities, and API hammering patterns. Adversaries leverage these methods to evade automated sandbox analysis environments that enforce execution time limits, blend malicious activity with normal operational windows, and ensure prior-stage payloads have completed. Common patterns include high-iteration ping loops (e.g., 'ping 8.8.8.8 -n 70' as used by Mustang Panda), PowerShell Start-Sleep with extended durations, CMD timeout commands, Linux sleep invocations from scripting contexts, and repeated Native API function calls (NtDelayExecution) that serve no functional purpose beyond timing control.

What is T1678 Delay Execution?

Delay Execution (T1678) maps to the Defense Evasion tactic — the adversary is trying to avoid being detected in MITRE ATT&CK.

This page provides production-ready detection logic for Delay Execution, covering the data sources and telemetry it touches: Microsoft Defender for Endpoint. The queries below are rated medium severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Defense Evasion
Technique
T1678 Delay Execution
Canonical reference
https://attack.mitre.org/techniques/T1678/
Microsoft Sentinel / Defender
kusto
let PingLoopThreshold = 30;
let SleepThresholdSeconds = 300;
DeviceProcessEvents
| where TimeGenerated > ago(24h)
| where (
    // Ping-based delay: high iteration count (Mustang Panda T1678 pattern)
    (
        FileName =~ "ping.exe"
        and ProcessCommandLine matches regex @"(?i)-n\s+(3[0-9]|[4-9]\d|\d{3,})"
    )
    // PowerShell Start-Sleep with 300+ seconds
    or (
        FileName in~ ("powershell.exe", "pwsh.exe")
        and ProcessCommandLine matches regex @"(?i)(Start-Sleep|sleep)\s+(-Seconds\s+|-s\s+)?[3-9]\d{2,}"
    )
    // CMD timeout with 300+ seconds
    or (
        FileName =~ "timeout.exe"
        and ProcessCommandLine matches regex @"(?i)/t\s+[3-9]\d{2,}"
    )
    // Wscript/Cscript sleep via WScript.Sleep with 300000+ ms
    or (
        FileName in~ ("wscript.exe", "cscript.exe")
        and ProcessCommandLine matches regex @"(?i)WScript\.Sleep\s*\(\s*[3-9]\d{5,}"
    )
    // Bash/sh sleep on Linux/macOS
    or (
        FileName in~ ("sleep", "bash", "sh", "zsh", "python", "python3")
        and ProcessCommandLine matches regex @"(?i)(^|\s|;|&&|\|\|)sleep\s+[3-9]\d{2,}"
    )
)
| extend
    DelayMethod = case(
        FileName =~ "ping.exe", "ping-loop",
        FileName in~ ("powershell.exe", "pwsh.exe"), "powershell-sleep",
        FileName =~ "timeout.exe", "cmd-timeout",
        FileName in~ ("wscript.exe", "cscript.exe"), "wscript-sleep",
        "shell-sleep"
    ),
    PingCount = case(
        FileName =~ "ping.exe",
        toint(extract(@"(?i)-n\s+(\d+)", 1, ProcessCommandLine)),
        int(null)
    ),
    SleepSeconds = case(
        FileName in~ ("powershell.exe", "pwsh.exe"),
        toint(extract(@"(?i)(?:Start-Sleep|-s)\s+(\d+)", 1, ProcessCommandLine)),
        FileName =~ "timeout.exe",
        toint(extract(@"(?i)/t\s+(\d+)", 1, ProcessCommandLine)),
        int(null)
    )
| project
    TimeGenerated,
    DeviceName,
    DeviceId,
    AccountName,
    AccountDomain,
    FileName,
    FolderPath,
    ProcessCommandLine,
    ProcessId,
    InitiatingProcessFileName,
    InitiatingProcessCommandLine,
    InitiatingProcessFolderPath,
    InitiatingProcessId,
    InitiatingProcessParentFileName,
    DelayMethod,
    PingCount,
    SleepSeconds
| order by TimeGenerated desc

Detects execution of common delay techniques used by adversaries including high-iteration ping loops (>=30 counts), PowerShell Start-Sleep with durations >=300 seconds, CMD timeout with >=300 second delays, WScript.Sleep with >=300000 milliseconds, and shell sleep commands with long durations. Captures the parent process context to identify suspicious execution chains.

medium severity medium confidence

Data Sources

Microsoft Defender for Endpoint

Required Tables

DeviceProcessEvents

False Positives

  • Network diagnostic scripts legitimately using ping with high iteration counts for connectivity monitoring
  • IT automation tools and deployment scripts using sleep/timeout to wait for service readiness or restart completion
  • PowerShell-based health check scripts polling for application startup with Start-Sleep loops
  • Scheduled maintenance scripts using timeout to serialize sequential operations
  • Developer test scripts intentionally sleeping to simulate slow network conditions

Sigma rule & cross-platform mapping

The detection logic for Delay Execution (T1678) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource:

logsource:
  category: process_creation
  product: windows

Browse the community-maintained Sigma rules for this technique:

Last updated: 2026-03-20 Research depth: deep
References (1)

Testing Methodology

Validate this detection against 5 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Ping Loop Delay - Windows (Mustang Panda Pattern)

    Expected signal: DeviceProcessEvents: FileName=ping.exe, ProcessCommandLine contains '-n 60', followed by cmd.exe creating delay_test_marker.txt. Sysmon EventCode=1 for ping.exe with -n 60 parameter.

  2. Test 2PowerShell Start-Sleep Delay

    Expected signal: DeviceProcessEvents: FileName=powershell.exe, ProcessCommandLine contains 'Start-Sleep -Seconds 600'. PowerShell ScriptBlock log (Event 4104) will contain 'Start-Sleep -Seconds 600' if script block logging is enabled.

  3. Test 3CMD Timeout Delay Before Payload

    Expected signal: DeviceProcessEvents: FileName=timeout.exe, ProcessCommandLine contains '/t 600'. Parent process cmd.exe command line shows chained execution with &&.

  4. Test 4Linux Shell Sleep Delay

    Expected signal: Auditd execve syscall log showing sleep process with argument 600, parent process bash. Syslog entry if process accounting enabled.

  5. Test 5WScript.Sleep Delay via VBScript

    Expected signal: DeviceProcessEvents: FileName=cscript.exe with ProcessCommandLine referencing sleep_test.vbs in %TEMP%. Sysmon Event 1 with parent process and full command line.


Response Playbook

Triage

  1. Step 1: Identify the parent process — review InitiatingProcessFileName and InitiatingProcessCommandLine. A delay command spawned by cmd.exe, wscript.exe, or powershell.exe under a non-admin user or from a temp/user-writable path is high priority.
  2. Step 2: Check the grandparent process (InitiatingProcessParentFileName) to understand the full execution chain. Legitimate admin tools will show known parent paths; malware often shows browser.exe, winword.exe, or explorer.exe as ancestors.
  3. Step 3: For ping-loop delays, check what command follows the ping using timeline correlation — query DeviceProcessEvents for the same device/PID tree ±5 seconds after the delay command to identify the deferred payload.
  4. Step 4: Examine the folder path of the initiating process. Executables in %TEMP%, %APPDATA%, or user-writable locations executing delay commands are strong indicators of malicious staging.
  5. Step 5: Cross-reference the AccountName against expected behavior — service accounts or non-interactive system accounts should not be spawning interactive delay commands.
  6. Step 6: Check DeviceNetworkEvents around the same time window for C2 beaconing, DNS lookups, or connection attempts that correlate with the post-delay execution phase.

Containment

  1. If the delay pattern is followed by confirmed malicious activity, isolate the endpoint via Defender for Endpoint's 'Isolate device' action to prevent lateral movement during the investigation window.
  2. Terminate any identified malicious processes via Live Response — obtain PID from the alert and run 'kill' via the Live Response session to interrupt staged payload execution.
  3. If the delay is part of a script (PS1, VBS, BAT), locate and quarantine the script file identified in the execution chain using Defender's file quarantine capability.
  4. Block any IOC hashes (from identified payload files) in Defender for Endpoint custom indicators to prevent re-execution across the fleet.

Evidence Collection

  1. Export the full process tree from Defender for Endpoint's Device Timeline for the affected host, covering 2 hours before and after the alert timestamp.
  2. Collect the script or binary file from the identified FolderPath using Live Response file collection for static/dynamic malware analysis.
  3. Capture prefetch files from C:\Windows\Prefetch for the identified process names (ping.exe, timeout.exe, powershell.exe) — prefetch timestamps can confirm first execution time.
  4. Export DeviceProcessEvents for the affected DeviceId for a 4-hour window: look for execution immediately following the delay period to identify the deferred payload.
  5. Collect memory dump of any suspicious parent or child process still running using Sysinternals ProcDump via Live Response.
  6. Review Windows Event Log System (Event 7045) and Security (Event 4688 with command line auditing) for any service installations or new process creations in the delay window.

Escalation Criteria

  • ! Escalate immediately if the post-delay process execution involves credential access tools (mimikatz, procdump targeting lsass.exe, comsvcs.dll MiniDump) — indicates the delay was used to time credential harvesting.
  • ! Escalate if the delay pattern is found on multiple endpoints within the same time window — indicates a coordinated campaign or worm-like spreading behavior.
  • ! Escalate if network connections to external IPs are established immediately following the delay period — indicates the delay was used to time C2 check-in or data exfiltration.
  • ! Escalate if the initiating process is a document viewer (winword.exe, excel.exe, acrord32.exe) or browser — indicates successful phishing/drive-by leading to staged execution.
  • ! Escalate if delay commands are found running under SYSTEM, LOCAL SERVICE, or service account contexts with no associated scheduled maintenance window.

Investigation Guide

Forensic Artifacts

  • > Prefetch files: C:\Windows\Prefetch\PING.EXE-*.pf and TIMEOUT.EXE-*.pf — timestamp indicates first and last execution times
  • > Windows Event Log Security (Event 4688) with process command line auditing enabled — captures full command line including delay parameters
  • > Sysmon Event ID 1 logs with full command line and parent process context
  • > PowerShell ScriptBlock logging (Event 4104 in Microsoft-Windows-PowerShell/Operational) — captures Start-Sleep calls within scripts even if process command line is obfuscated
  • > Scheduled task XML files in C:\Windows\System32\Tasks\ — if delay is implemented via chained scheduled tasks
  • > Batch/VBS/PS1 script files in %TEMP%, %APPDATA%\Roaming, or user home directories
  • > Linux: /var/log/auth.log, /var/log/syslog, auditd logs (execve syscalls) for sleep command invocations from scripts
  • > macOS: Unified System Log (log show) for process execution events involving sleep commands from launchd or shell scripts

Tuning Guidance

Start by building an allowlist of known legitimate delay callers: deployment scripts, software installers, and monitoring agents often use sleep/timeout. Filter by InitiatingProcessFolderPath to exclude known-good paths (C:\Windows\System32\, C:\Program Files\, known admin tools). For ping-loop tuning, set the threshold based on your environment's acceptable ping count — most legitimate network tests stay below 20; raising the threshold to 50 will significantly reduce false positives. For PowerShell, scope to non-interactive sessions (InitiatingProcessParentFileName != 'explorer.exe' for interactive shells) or enforce enrichment with user context before alerting. In high-noise environments, combine this detection with a second indicator (e.g., subsequent execution from temp path) as a composite rule rather than standalone alert.


Hunting Queries

Hunts for the Mustang Panda execution pattern where a ping-loop delay is immediately followed by execution of a binary from a user-writable directory — identifying the deferred payload launched after the delay period expires.

Hunting — KQL
kql
// Hunt for ping-delay chained with executable launch (Mustang Panda pattern)
let PingDelays = DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where FileName =~ "ping.exe"
| where ProcessCommandLine matches regex @"(?i)-n\s+(3[0-9]|[4-9]\d|\d{3,})"
| project PingTime=TimeGenerated, DeviceId, DeviceName, InitiatingProcessId, InitiatingProcessCommandLine, AccountName;
let SubsequentExecutions = DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where FileName !in~ ("ping.exe", "cmd.exe", "conhost.exe")
| project ExecTime=TimeGenerated, DeviceId, ExecFileName=FileName, ExecFolderPath=FolderPath, ExecCommandLine=ProcessCommandLine, InitiatingProcessId, AccountName;
PingDelays
| join kind=inner SubsequentExecutions on DeviceId, InitiatingProcessId
| where ExecTime between (PingTime .. (PingTime + 5m))
| where ExecFolderPath has_any ("%TEMP%", "\\Users\\", "\\AppData\\")
| project PingTime, ExecTime, DeviceName, AccountName, InitiatingProcessCommandLine, ExecFileName, ExecCommandLine, ExecFolderPath
| order by PingTime desc
Hunting — SPL
spl
index=* sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
| eval is_ping_delay=if(like(Image, "%\\ping.exe") AND match(CommandLine, "(?i)-n\\s+(3[0-9]|[4-9]\\d|\\d{3,})"), 1, 0)
| where is_ping_delay=1
| eval ping_parent_pid=ParentProcessId
| eval ping_time=_time
| eval ping_host=Computer
| table ping_time, ping_host, ping_parent_pid, CommandLine, ParentImage
| join type=inner ping_parent_pid [
    search index=* sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
    NOT (Image LIKE "%\\ping.exe" OR Image LIKE "%\\cmd.exe" OR Image LIKE "%\\conhost.exe")
    | where like(Image, "%\\Temp%") OR like(Image, "%\\AppData%") OR like(Image, "%\\Users%")
    | eval follow_time=_time
    | table follow_time, Computer, ping_parent_pid, Image, CommandLine
    | rename ParentProcessId AS ping_parent_pid
]
| where follow_time > ping_time AND follow_time < (ping_time + 300)
| table ping_time, follow_time, Computer, ParentImage, Image, CommandLine

Hunts for API hammering patterns by identifying non-system processes that spawn 10 or more child processes within a 60-second window with low diversity — indicative of a process making repeated NtCreateProcess/NtDelayExecution calls to waste analysis environment time budgets.

Hunting — KQL
kql
// Hunt for API hammering via repeated NtDelayExecution / excessive process creation bursts
// Identifies processes spawning 10+ child processes within a 60-second window (API hammering behavior)
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| summarize
    ChildProcessCount = count(),
    UniqueChildImages = dcount(FileName),
    ChildImages = make_set(FileName, 20),
    FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated)
    by bin(TimeGenerated, 1m), DeviceId, DeviceName, InitiatingProcessFileName, InitiatingProcessFolderPath, InitiatingProcessCommandLine, AccountName
| where ChildProcessCount >= 10
| where UniqueChildImages <= 3
| extend DurationSeconds = datetime_diff('second', LastSeen, FirstSeen)
| where DurationSeconds <= 60
| where InitiatingProcessFolderPath !has_any (":\\Windows\\System32\\", ":\\Windows\\SysWOW64\\")
| project FirstSeen, DeviceName, AccountName, InitiatingProcessFileName, InitiatingProcessCommandLine, ChildProcessCount, UniqueChildImages, ChildImages, DurationSeconds
| order by ChildProcessCount desc
Hunting — SPL
spl
index=* sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
| bucket span=1m _time
| stats count AS child_count, dc(Image) AS unique_images, values(Image) AS child_images BY _time, Computer, ParentImage, ParentCommandLine, User
| where child_count >= 10 AND unique_images <= 3
| where NOT (ParentImage LIKE "%\\System32%" OR ParentImage LIKE "%\\SysWOW64%")
| table _time, Computer, User, ParentImage, ParentCommandLine, child_count, unique_images, child_images
| sort -child_count

Hunts for PowerShell ScriptBlock logging events containing sleep API calls with long durations, including .NET Thread.Sleep calls used in advanced implants — catches cases where the process command line appears benign but the script block reveals the delay technique.

Hunting — KQL
kql
// Hunt for delay execution via PowerShell pipeline: sleep embedded in larger obfuscated script
DeviceEvents
| where TimeGenerated > ago(7d)
| where ActionType == "PowerShellCommand"
| where AdditionalFields has_any ("Start-Sleep", "[System.Threading.Thread]::Sleep", "::Sleep(", "WScript.Sleep")
| extend PSCommand = tostring(AdditionalFields)
| where PSCommand matches regex @"(?i)(Start-Sleep|Thread\]::Sleep|WScript\.Sleep).*([3-9]\d{2,}|\d{4,})"
| project TimeGenerated, DeviceName, AccountName, PSCommand, InitiatingProcessFileName, InitiatingProcessCommandLine
| order by TimeGenerated desc
Hunting — SPL
spl
index=* sourcetype="WinEventLog:Microsoft-Windows-PowerShell/Operational" EventCode=4104
| where match(ScriptBlockText, "(?i)(Start-Sleep|\\[System\\.Threading\\.Thread\\]::Sleep|WScript\\.Sleep)")
| rex field=ScriptBlockText "(?i)(?:Start-Sleep|-s|-Seconds|Thread\\]::Sleep\\(|WScript\\.Sleep\\()\\s*(?:-\\w+\\s+)?(?<sleep_val>[0-9]+)"
| where isnotnull(sleep_val) AND tonumber(sleep_val) >= 300
| table _time, Computer, UserID, ScriptBlockText, sleep_val
| sort -tonumber(sleep_val)

Atomic Red Team Tests

Test 1 Ping Loop Delay - Windows (Mustang Panda Pattern)
windows

Simulates the Mustang Panda technique of using ping with high iteration count to create a delay before executing a payload. This tests detection of ping.exe with -n parameter >=30.

Command

powershell
cmd.exe /c ping 127.0.0.1 -n 60 > nul && echo Payload execution would happen here > %TEMP%\delay_test_marker.txt

Cleanup

powershell
del /f %TEMP%\delay_test_marker.txt 2>nul

Expected Telemetry

DeviceProcessEvents: FileName=ping.exe, ProcessCommandLine contains '-n 60', followed by cmd.exe creating delay_test_marker.txt. Sysmon EventCode=1 for ping.exe with -n 60 parameter.

Expected Detection

Alert on ping.exe with -n count >= 30. The subsequent file creation in %TEMP% should also correlate as post-delay activity.

Test 2 PowerShell Start-Sleep Delay
windows

Uses PowerShell Start-Sleep to delay execution for 600 seconds, simulating a malware staging delay that exceeds typical sandbox analysis windows.

Command

powershell
powershell.exe -NoProfile -NonInteractive -Command "Write-Host 'Pre-delay'; Start-Sleep -Seconds 600; Write-Host 'Post-delay payload'"

Cleanup

powershell
Stop-Process -Name powershell -Force -ErrorAction SilentlyContinue (run from separate shell if needed)

Expected Telemetry

DeviceProcessEvents: FileName=powershell.exe, ProcessCommandLine contains 'Start-Sleep -Seconds 600'. PowerShell ScriptBlock log (Event 4104) will contain 'Start-Sleep -Seconds 600' if script block logging is enabled.

Expected Detection

Alert on powershell.exe with Start-Sleep duration >= 300 seconds.

Test 3 CMD Timeout Delay Before Payload
windows

Uses the built-in Windows timeout.exe command to delay execution for 600 seconds before simulating payload execution — a common technique in commodity malware batch scripts.

Command

powershell
cmd.exe /c timeout /t 600 /nobreak && echo DelayedPayload > %TEMP%\timeout_test_output.txt

Cleanup

powershell
del /f %TEMP%\timeout_test_output.txt 2>nul

Expected Telemetry

DeviceProcessEvents: FileName=timeout.exe, ProcessCommandLine contains '/t 600'. Parent process cmd.exe command line shows chained execution with &&.

Expected Detection

Alert on timeout.exe with /t value >= 300 seconds.

Test 4 Linux Shell Sleep Delay
linux

Simulates a Linux-based adversary using sleep to delay payload execution, as seen in Linux malware and post-exploitation frameworks.

Command

bash
bash -c 'echo "Pre-delay" && sleep 600 && echo "Payload execution" > /tmp/sleep_test_marker.txt'

Cleanup

bash
rm -f /tmp/sleep_test_marker.txt

Expected Telemetry

Auditd execve syscall log showing sleep process with argument 600, parent process bash. Syslog entry if process accounting enabled.

Expected Detection

Alert on sleep command with duration >= 300 invoked from a shell script context with subsequent file creation in /tmp.

Test 5 WScript.Sleep Delay via VBScript
windows

Uses WScript.Sleep in a VBScript to delay execution by 10 minutes (600000 ms), commonly seen in phishing payloads that use VBS droppers with built-in sandbox evasion delays.

Command

powershell
echo WScript.Sleep(600000) > %TEMP%\sleep_test.vbs && cscript.exe //nologo %TEMP%\sleep_test.vbs

Cleanup

powershell
del /f %TEMP%\sleep_test.vbs 2>nul

Expected Telemetry

DeviceProcessEvents: FileName=cscript.exe with ProcessCommandLine referencing sleep_test.vbs in %TEMP%. Sysmon Event 1 with parent process and full command line.

Expected Detection

Alert on cscript.exe/wscript.exe executing a script from %TEMP%. If WScript.Sleep call is extracted from script content, alert on duration >= 300000ms.

Related Detections