T1678 Splunk · SPL

Detect Delay Execution in Splunk

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.

MITRE ATT&CK

Tactic
Defense Evasion
Technique
T1678 Delay Execution
Canonical reference
https://attack.mitre.org/techniques/T1678/

SPL Detection Query

Splunk (SPL)
spl
index=* sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
| eval Image_lower=lower(Image)
| eval cmdline=coalesce(CommandLine, "")
| where (
    (
        like(Image_lower, "%\\ping.exe")
        AND match(cmdline, "(?i)-n\\s+(3[0-9]|[4-9]\\d|\\d{3,})")
    )
    OR (
        (like(Image_lower, "%\\powershell.exe") OR like(Image_lower, "%\\pwsh.exe"))
        AND match(cmdline, "(?i)(Start-Sleep|sleep)\\s+(-[Ss]\\s+|-Seconds\\s+)?[3-9]\\d{2,}")
    )
    OR (
        like(Image_lower, "%\\timeout.exe")
        AND match(cmdline, "(?i)/t\\s+[3-9]\\d{2,}")
    )
    OR (
        (like(Image_lower, "%\\wscript.exe") OR like(Image_lower, "%\\cscript.exe"))
        AND match(cmdline, "(?i)WScript\\.Sleep\\s*\\(\\s*[3-9]\\d{5,}")
    )
)
| eval delay_type=case(
    like(Image_lower, "%\\ping.exe"), "ping-loop-delay",
    like(Image_lower, "%\\powershell.exe") OR like(Image_lower, "%\\pwsh.exe"), "powershell-sleep",
    like(Image_lower, "%\\timeout.exe"), "cmd-timeout-delay",
    like(Image_lower, "%\\wscript.exe") OR like(Image_lower, "%\\cscript.exe"), "wscript-sleep",
    true(), "other-delay"
)
| eval ping_count=if(like(Image_lower, "%\\ping.exe"), tonumber(replace(cmdline, ".*-n\\s+(\\d+).*", "\\1")), null())
| eval sleep_seconds=case(
    match(cmdline, "(?i)(?:Start-Sleep|-s|-Seconds)\\s+(\\d+)"),
    tonumber(replace(cmdline, ".*(?:Start-Sleep|-s|-Seconds)\\s+(\\d+).*", "\\1")),
    match(cmdline, "(?i)/t\\s+(\\d+)"),
    tonumber(replace(cmdline, ".*/t\\s+(\\d+).*", "\\1")),
    true(), null()
)
| table _time, Computer, User, Image, CommandLine, ParentImage, ParentCommandLine, delay_type, ping_count, sleep_seconds
| sort -_time
medium severity medium confidence

Detects delay execution techniques via Sysmon Process Create events (EventCode 1). Identifies ping-loop delays, PowerShell Start-Sleep, CMD timeout delays, and WScript.Sleep calls with thresholds set to filter out short operational waits. Parent process context is captured for execution chain analysis.

Data Sources

Sysmon

Required Sourcetypes

XmlWinEventLog:Microsoft-Windows-Sysmon/Operational

False Positives & Tuning

  • Network operations team scripts pinging endpoints with high counts for availability testing
  • Software installers using timeout to wait for Windows services to restart after configuration
  • CI/CD pipeline scripts sleeping between health-check retry attempts during deployment
  • IT configuration management tools (Ansible, Chef, Puppet) using sleep for dependency sequencing
  • Monitoring agents using periodic sleep loops between polling intervals

Other platforms for T1678


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 1 Ping 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 2 PowerShell 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 3 CMD 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 4 Linux 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 5 WScript.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.

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

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

Related Techniques

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