How T1678 delay execution hides intrusions from SOC timelines
A SOC lead often sees alerts that seem to appear from nowhere, hours after a suspicious file was staged, and the timeline no longer lines up with the moment the file landed. T1678 Delay execution is a Stealth technique in which an adversary postpones the point at which its activity runs, so the event that matters most is separated in time from the event that delivered it. The gap makes correlation harder, because analysts searching a narrow window around the initial file write will find nothing that looks malicious. ATT&CK defines the Stealth tactic (TA0005) as follows: "The adversary is trying to hide and conceal their actions, appearing as normal behavior." At a high level, T1678 serves that goal by moving execution out of the window that most detection rules and analysts examine.
Treat the details of the technique as a starting point, not a settled fact. Before you write rules or scope a rehearsal, confirm the technique's exact description, the platforms it lists and whether it has sub-techniques on the ATT&CK page for the version your team uses. ATT&CK v19, released April 28, 2026, split the former Defense Evasion tactic into Stealth, which keeps the ID TA0005, and Defense Impairment, which has ID TA0112. Older mappings may still show techniques under Defense Evasion, so every detection mapping, coverage report and SOC runbook should name the ATT&CK version it targets. The MITRE ATT&CK updates page lists release notes that help you check whether a mapping has moved.
For the SOC, the practical question is whether your timeline reconstruction can connect a delayed execution back to its origin. Check that process creation, module load and script execution telemetry is retained long enough to span the gap you expect, and that correlation logic does not discard events simply because they fall outside a short default window. Decide who owns the long-window hunt, how staged files are tagged when they are written, and which hosts must be covered first. Write these decisions down before an incident, so the analyst reviewing a late alert knows where to look.
Which telemetry reveals delayed execution on each platform
This table maps the telemetry named for T1678 to the signal each source can surface, the platforms where it applies and the open-source collectors that gather it. Treat each row as a starting point for a detection hypothesis, then validate it in your own environment. The main takeaway is that delay shows up as timing between related records, so correlate time gaps across events rather than relying on a single log entry.
| Telemetry and data component | Signal to look for | Platforms and open-source collectors |
|---|---|---|
| Process Creation (DC0032) | A child process starts long after its parent, with no user action in between, or a scheduler or helper launches a payload-like process after a pause. | Windows: Sysmon and Windows event logs forwarded to Wazuh. Linux: auditd execution records and Sysmon for Linux. macOS: endpoint logs collected with Velociraptor, confirm field coverage. |
| Module Load (DC0016) | A process loads timing or sleep-related libraries it has no operational reason to use, or loads them just before a long idle period. | Windows: image load events via Sysmon and Wazuh. Linux: confirm shared-object visibility with auditd rules or Velociraptor artifacts. macOS: confirm library-load logging for your endpoint tooling. |
| Script Execution (confirm DC ID) | An interpreter runs a script that waits, sleeps or polls a clock before performing further actions, especially when the script was recently written. | Windows: PowerShell script block logging forwarded to Wazuh. Linux: interpreter activity captured through auditd. macOS: confirm script and interpreter logging. Confirm the DC ID in the enterprise-attack 20.0 bundle before citing it. |
| Command Execution (DC0064) | Shell or command lines that include wait durations, scheduled timers or deferred start parameters, seen alongside otherwise routine activity. | Windows: command-line capture in Sysmon and Wazuh. Linux: auditd command records and Wazuh. macOS: Velociraptor collection, confirm command-line fields in your build. |
| File Creation (DC0039) | A staged file written to disk during one session and executed much later, often from a path that normal users rarely touch. | Windows: Sysmon file creation events via Wazuh. Linux: auditd file watch rules or Wazuh file integrity monitoring. macOS: file system events via Velociraptor, confirm retention. |
| Network Connection Creation (DC0082) | An outbound connection that begins well after the related process started, matching the earlier spawn by process identifier and host. | Windows: Sysmon network events via Wazuh. Linux: Zeek or Suricata sensor logs correlated with host telemetry. macOS: confirm network connection logging available to your collector. |
Detection ideas for delayed execution: logic, tuning and false positives
Delayed execution is hard to see because the trigger and the payload are separated in time and often in process lineage. The cards below describe correlation logic in words, the thresholds to tune in your own environment, and the benign activity that will fill your queue if you do not account for it first.
Correlate creation to later execution
Link a process creation event that schedules or registers future work to the execution event it eventually produces, keyed on host, user and the child process identifier. The core decision is the time window: start with a window your own baseline supports, then widen or narrow it after reviewing real hits in a test range. Check whether the scheduled action runs under a different account or session than the one that created it, since that gap is often what the logic should surface. Tune the window per host role, because servers that run batch work will show longer gaps than user workstations.
Flag module loads from unusual parents
Alert when a module or script host loads from a parent process that does not normally load it, such as a scheduler or service wrapper invoking an interpreter or loader outside its usual path. Build the list of expected parent-to-child pairs from at least one full business cycle on representative hosts, then treat new pairs as review items rather than verdicts. Pay attention to the signed status and install location of the loaded module, because a valid signature in an unexpected directory is a stronger signal than either fact alone. Set the alert threshold on rarity across your fleet, not on a single occurrence.
Script execution from scheduled contexts
Review script execution events where the parent is a task runner, cron-style scheduler or service manager and the script content or path has not been seen before on that host. Use a tuned allowlist of approved script locations and hashes, maintained through your change process, so that routine maintenance stays quiet. Require the alert to carry the originating task definition, so responders can see who created it and when. Confirm that your logging captures script block or command content on Windows and shell history or audit records on Linux and macOS, since missing content turns this card into a guess.
Baseline legitimate deferred jobs
Build an inventory of approved deferred work, including maintenance windows, certificate renewals, log rotation, database housekeeping and endpoint management jobs, with owner, schedule and expected host set. Compare each observed deferred execution against that inventory and route unmatched items to review. Keep the inventory under change control so that new jobs are added before they run, not after an alert. Recheck the baseline after every major platform upgrade, because vendor updates frequently add or move scheduled tasks.
Known false positive sources
Expect noise from backup agents, patch management, endpoint and monitoring agents, configuration management and log shippers, since all of them schedule work, load modules and run scripts on a timer. Document each source with the process names, parent services and hosts involved, then suppress only the specific combination, not the whole product. Ask each vendor which scheduled jobs and module loads their agents perform, and confirm this against your own host inventory. Review suppressions quarterly, because an agent upgrade can change the pattern and silently hide a new behavior.
How to tune delayed execution detection on Linux, macOS and Windows
On Linux, deferred execution is usually visible through process creation records, scheduled job activity and script or interpreter command lines, so the first task is confirming that those sources reach the SOC with enough detail to be useful. Many hosts run scheduled work from system timers, cron, configuration management agents and package maintenance, and those jobs will look like deferred execution to a rule written without context. Build the baseline per host group, not fleet-wide, because a build server and a database host will have very different schedules.
- Process creation records: Confirm that the audit subsystem or your agent captures process creation with parent process, user and full command line on the hosts in scope.
- Scheduler activity: Collect cron and systemd timer activity so that scheduled starts can be correlated with the processes they launch.
- Baseline of normal jobs: Record which scheduled jobs run on each host group, at what times, under which accounts, and from which parent processes.
- Noise to tune out: Exclude known maintenance agents and backup jobs by path and parent process, not by broad user name, so that a compromised service account is still visible.
- Retention and time sync: Verify that hosts synchronize time reliably so that delay intervals can be reconstructed across sources.
Confirm the exact audit rule syntax, agent support and log field names against your Linux distribution and your Wazuh or agent documentation before deploying.
On macOS, deferred execution commonly appears through launch agents and launch daemons, login items and scheduled tasks managed by the launch framework. Endpoint management tools, software updaters, sync clients and developer tooling all create recurring activity that can resemble delayed launches. The tuning work is therefore about separating managed, expected launch items from unexpected ones, and that requires an inventory before any rule is tuned.
- Process and script telemetry: Ensure process creation and script or interpreter execution events are collected from endpoints, including parent process and command line.
- Launch item inventory: Document every launch agent and daemon approved for each device group, including the path, owner and label.
- Baseline of normal activity: Measure how often approved launch items start and at what intervals, separately for user and managed devices.
- Noise to tune out: Suppress known updater and management agent activity by signed bundle identifier or known path, and review those exclusions after each major software change.
- Unsigned or relocated items: Keep alerts on launch items that point to user-writable directories or unsigned binaries, because those are rarely part of a managed baseline.
Confirm which unified logging and endpoint security telemetry your macOS fleet can export, and the field names your SIEM receives, with the vendor documentation for your endpoint agent.
On Windows, deferred execution usually shows up as scheduled task creation and execution, service activity, and script host or PowerShell events that start later than the triggering action. Because Windows hosts run many built-in and vendor scheduled tasks, the baseline must be built from the real task inventory, with each task's author, trigger and run account recorded. Without that inventory, almost every scheduled task will look suspicious and the SOC will stop trusting the alerts.
- Task and process telemetry: Confirm that process creation with command line is logged, along with scheduled task registration and execution events, on servers and workstations in scope.
- Script execution logging: Enable script block and module logging where policy allows, so that deferred scripts are recorded with their content.
- Baseline of scheduled tasks: Export the task inventory per host role and record author, trigger, run account and expected run times.
- Noise to tune out: Exclude vendor and Microsoft maintenance tasks by exact task path and author, and review those exclusions after patching or agent upgrades.
- Correlation window: Tune the time window between task creation and first execution so that legitimate short delays do not generate separate alerts.
Confirm the event IDs, log channels and sizing for your Windows estate against Microsoft's documentation and your SIEM parser, and check the volume with your own estimates before enabling collection everywhere.
How to validate that the T1678 detection fires
This sequence proves, inside a private cyber range, that the T1678 Delay execution detection produces the expected telemetry, alerts and correlations before it is trusted in production. It ends with a documented record of what worked, what did not and which tuning changes were made.
Agree the emulation plan and scope in writing
The security lead, the detection engineer and the range operator agree in writing which T1678 behaviors will be emulated, on which platforms (Linux, macOS and Windows), which hosts and accounts are in scope, and which ATT&CK version the mapping targets. Confirm the ATT&CK version against the MITRE updates page before writing any detection, because releases can rename or deprecate techniques. The step is done when a signed scope note exists and every in-scope host is listed in the range inventory.
Define expected telemetry and alerts per step
For each agreed behavior, the detection engineer writes down the data components expected to record it, such as Process Creation and Module Load, along with the Script Execution telemetry where it applies, and the alert the rule should raise. This expectation sheet is written before the run so that results cannot be judged after the fact. The step is done when each row names a source, a field set, a rule identifier and a pass or fail condition.
Confirm telemetry collection is healthy
The range operator checks that the endpoint agents, log forwarders and SIEM or Wazuh indexes are running, time-synchronized and receiving events from every in-scope host before the emulation starts. A test event on each host should appear in the central platform within the expected ingestion path. The step is done when the operator signs a pre-run health check showing no dropped sources.
Run the emulation in an isolated range
The red team or range operator runs the agreed emulation steps inside the isolated cyber range, with no route to production networks or external services. A second person logs each step with its start time, host and platform, so that the run can be reconstructed. The step is done when the run log matches the scope note one to one and no out-of-scope action appears.
Record events and alert timestamps
After the run, the detection engineer exports the raw endpoint events, the rule hits and the case or alert records from the SIEM or Wazuh manager, and stores them with the run log. Timestamps are compared across sources to confirm that clock offsets do not hide ordering. The step is done when every emulated step has either matching events and an alert, or a recorded absence.
Measure whether correlation works as designed
The detection engineer checks whether the rule fired on the expected events, whether multi-event correlation linked the steps into one finding and whether the alert carried the fields an analyst needs. Each result is marked as detected, partially detected or missed, against the expectation sheet from earlier. The step is done when every expectation has a recorded verdict with evidence attached.
Document gaps and tuning changes
Gaps are logged as tickets with the affected platform, telemetry source and suspected cause, such as a missing log source, a field name mismatch or an over-broad exclusion. Any tuning change is reviewed, tested again in the range and recorded with its version and reason, so that false-positive effects on normal administration are visible. The step is done when a validation report lists each finding, its owner and the retest result.
Preventive controls that reduce delayed execution risk
The mitigations below are the ATT&CK mitigations most often mapped to Stealth techniques in the Enterprise 20.0 bundle, and they limit delayed execution by restricting what runs, who can schedule it and where it can write. Confirm on the T1678 technique page which of these ATT&CK currently maps to T1678 before you rely on them in a control set.
Audit logging of scheduled activity
Audit (M1047) is the mitigation that makes delayed execution visible in the first place. Turn on the operating system and platform audit settings that record process creation, scheduled task or cron changes and sleep-based script launches, and forward those records to a central store that the attacker cannot quietly edit. Without these records, a delayed action leaves no trace until it fires. Confirm that retention covers the window between a scheduling event and its later execution.
Behavior prevention on endpoints
Behavior Prevention on Endpoint (M1040) uses endpoint controls that act on what a process does rather than on a file signature. For delayed execution, this means blocking or alerting when a scripting host starts a long wait and then spawns a child process, or when a benign-looking binary begins launching interpreters after a pause. Ask your endpoint vendor which behavioral rules it ships for scheduled and sleeping process chains and how it reports them.
Execution prevention through allowlisting
Execution Prevention (M1038) limits which binaries, scripts and interpreters can run at all. Application control policies, such as allowlisting on Windows or executable restrictions on Linux and macOS, stop a delayed payload from starting even after its timer expires. Review exceptions for scheduling utilities and script hosts, since those are the components a delayed action most often relies on. Expect ongoing effort to keep the allowlist current as software changes.
Controlled user account management
User Account Management (M1018) reduces who can create or modify scheduled work. Restrict the rights needed to register scheduled tasks, cron entries or launch agents to a defined administrative group, and review that group on a fixed cadence. Check for accounts that can schedule work for other users, because those accounts let an actor set up execution that runs under a different identity and outlives their session.
Restricted file and directory permissions
Restrict File and Directory Permissions (M1022) limits where scheduled content and its supporting scripts can be written or altered. Set write access on task directories, cron folders, startup locations and script repositories so that only change-controlled identities can modify them. This prevents an actor from planting or editing a delayed action in a location the system will later read. Test the permissions against your own deployment tooling so that legitimate updates keep working.
Privileged account management for schedulers
Privileged Account Management (M1026) controls the high-privilege accounts that can change system schedulers and run work with elevated rights. Store those credentials in a vault, require approval and session recording for their use, and rotate them on a schedule your change process defines. A delayed action running under a privileged account has far greater reach, so confirm that scheduler service accounts are scoped to the tasks they actually perform.
What the SOC should do when a delayed execution alert fires
The first priority when a delayed execution alert fires is to decide whether it reflects an adversary or a legitimate scheduled job, and to do that before anyone touches the host. Start by checking the alert against the client's inventory of scheduled tasks, cron entries, launch agents and deployment automation for the affected host. Confirm the owner, the change record and the expected run time. Then rebuild the timeline between the creation event and the later execution event from Process Creation, File Creation and Module Load telemetry, noting who or what created the delayed job, from which parent process, under which account, and how long the gap was. A short gap that falls outside any approved change window is a stronger signal than a long gap that matches a known maintenance schedule. Record every assumption as you go.
Once the timeline is clear, scope the blast radius. Identify other hosts where the same creator, parent process, binary path or account appears, and check whether the account that created the job also appears in unrelated authentication events. Preserve the relevant telemetry before any cleanup: export the raw events from the Wazuh or SIEM indices, snapshot the affected endpoint through the client's approved forensic process, and confirm the retention period for each source with the platform owner, since short retention can erase the creation event before the investigation finishes. Containment should be the least disruptive option that stops further execution, such as disabling the specific job or isolating the host from the network, and it should be a decision recorded with the approver's name. Keep a decision log with timestamps, the evidence relied on and the reasons for each choice so the review can reconstruct the reasoning later. Escalate according to the client's incident response plan, which should define severity thresholds, who is on call and when legal or privacy teams must be informed. Bring in incident response or forensic specialists when the creator cannot be attributed to an approved process, when credentials may be compromised, when more than one host shows the pattern, or when the scheduled action touches regulated data. Confirm in advance how DeployOpen or any other external responder would be engaged under the client's own contracts and runbooks, since those documents, not this page, decide who has authority over containment and evidence handling.
How to rehearse T1678 detection and response in a private cyber range
The range should be an isolated network that contains no route to production systems, corporate identity services or real customer data. Populate it with representative Linux, macOS and Windows endpoints that match the operating system builds, logging agents and security baselines your organization actually runs. A SIEM such as Wazuh receives events from those endpoints, and a collector such as Velociraptor provides on-demand host evidence when analysts need to confirm what a process did. Sizing, host counts and network topology depend on the client, so confirm them during scoping rather than copying a generic layout.
- Endpoint coverage: Include at least one host per operating system in scope, configured with the same audit policy and log forwarding as production.
- Telemetry path: Verify that process creation, module load and script execution events reach the SIEM with the fields your detection logic needs.
- Collection tooling: Confirm the collector can run approved artifacts on each endpoint without disabling logging.
- Isolation controls: Document egress blocks and the procedure for resetting hosts between runs.
- Access model: Limit range administration to named staff and record who can change the lab configuration.
Before the exercise starts, ask your range provider to show a clean baseline of events from each host so the team can tell lab noise from exercise activity.
Injects are scripted events that the exercise control team introduces into the range so that the SOC has something concrete to detect and reconstruct. For T1678, a useful inject describes a deferred activity: an action that is scheduled or conditioned to run later, so the original trigger and the eventual effect are separated in time. The SOC should not be told which host, account or scheduling mechanism is involved. Its job is to find the link between an early, quiet event and a later, visible one. Keep every inject described in general terms so the scenario can be reused across platforms without publishing a how-to.
- Deferred activity: A process starts on one endpoint and produces its visible effect only after a delay, so analysts must correlate events across time.
- Platform variation: Run comparable injects on Linux, macOS and Windows so each team tests its own logging coverage.
- Noise injection: Add ordinary administrative activity during the same window to test whether analysts can separate it from the scenario.
- Partial telemetry: Withhold one data source in a controlled inject to see whether the team recognizes the gap and documents it.
- Timed escalation: Release a follow-on event that forces a decision about containment or further collection.
After each inject, record which events were available, which were missing and which the team needed but did not have.
Success in this exercise is judged on the quality of the work, not on a single pass or fail result. A strong detection produces an alert that names the affected host, the process and the relevant time window, and that an analyst can act on without rebuilding the context from scratch. Triage should be consistent across shifts, and the case record should let a reviewer follow the reasoning without interviewing the analyst. Agree on these measures with the security lead before the exercise and review them in a structured debrief. Do not set numeric targets unless your own baseline supports them.
- Alert quality: Alerts identify the endpoint, the process lineage and the event time, and they fire on the scenario activity without flooding the queue.
- Triage consistency: Two analysts reviewing the same inject reach the same classification and cite the same evidence.
- Time to triage: Record how long each step takes and compare results across runs to find bottlenecks rather than chasing a fixed number.
- Documentation quality: Case notes state what was observed, what was inferred and what remains unverified.
- Response decisions: Containment and collection steps match the agreed playbook, and any deviation is explained.
At the end of the debrief, confirm which detection rules need tuning and which telemetry gaps need a remediation owner.
Questions detection engineers ask about T1678 Delay execution
How do you correlate delayed execution events when the gap between steps is long?
Correlate on stable keys rather than on time windows alone. Delayed execution often separates the first event, such as a process or script being staged, from the later event that runs it, so a short correlation window will miss the pair. Use host identifiers, user or session identifiers, the executable path or hash, and parent-child process relationships to link events. Keep the raw events for the full period you intend to investigate, and store the correlation logic as a saved search or rule that runs over that longer horizon. Confirm the query cost on your SIEM before widening the window, because long lookbacks on high-volume Process Creation data can be expensive to run on a schedule.
How do you separate delayed execution from legitimate scheduled jobs?
Start with an inventory of approved schedulers and scheduled jobs on each platform, including cron, systemd timers, launchd agents and Windows Task Scheduler entries, and record their owners and expected binaries. Then alert on deviations from that baseline, such as a new scheduled entry, a changed command line, or an execution that comes from an unexpected parent or user. Treat the inventory as a living control, reviewed on the same cadence as change management. Tune exclusions by exact match on path, signer and job name rather than by broad patterns, and log every exclusion so reviewers can see what was suppressed and why.
Which logs should you retain for delayed execution detection, and for how long?
At minimum, retain process creation events with command lines, module load events where your platform provides them, script execution logs such as PowerShell script block logging where enabled, and the logs from task schedulers and cron or systemd journals. Retention length is set by your own policy and by the regulations that apply to your sector, so confirm the period with your compliance lead and legal counsel rather than copying a figure from a vendor guide. Document which sources are collected, where they are stored, who can access them, and how long they remain searchable online versus archived. Check that the retention setting on your log platform matches the policy you signed off.
How do you tell whether T1678 maps to a sub-technique in the ATT&CK version you use?
Check the sub-technique list in the Enterprise ATT&CK bundle for the exact version you target, rather than relying on memory or on a secondary blog. MITRE publishes each version as a STIX 2.1 bundle in the attack-stix-data repository, so you can query the relationships for T1678 in the Enterprise 20.0 bundle and confirm whether any sub-techniques are listed. Record the version number next to every detection mapping in your catalog. If a future release changes the structure, your record will show what was true when the rule was written. Ask your detection content owner to repeat the check at each version upgrade.
How do you keep ATT&CK mappings current across releases?
Treat each ATT&CK release as a change event with a named owner and a review checklist. MITRE's updates pages describe what changed in each release. ATT&CK v18 replaced detections in technique pages with detection strategies and analytics and deprecated some data sources. ATT&CK v19 split the Enterprise Defense Evasion tactic into Stealth, which keeps ID TA0005, and Defense Impairment, which is new. Releases can also rename, deprecate or revoke techniques, so compare your mappings against the new bundle, update the version field on each rule, and retest the affected detections in your range before promoting them. Keep the diff and the test results as evidence.
How do you measure whether the delayed execution detection holds after tuning?
Measure the detection against labeled test cases, not only against alert volume. Build a set of benign scheduled jobs and a set of simulated delayed execution events in a private cyber range, then record which ones fire, how long each takes to alert, and which benign jobs trigger false positives. Repeat the same test set after every tuning change, so you can see whether exclusions have hidden real activity. Track false positive rate and time to alert over time, and review suppressed events on a fixed schedule. DeployOpen can plan and run this kind of rehearsal in a private range as a fixed-scope engagement, with the test cases and success criteria agreed in writing first.
How DeployOpen builds T1678 detections and range exercises
DeployOpen works on T1678 Delay execution as a fixed-scope engagement inside your own environment, starting from the telemetry you already collect. The work produces detection logic, validation evidence and a cyber range exercise that your team can repeat.
How we scope
- Confirm which operating systems in your estate (Linux, macOS, Windows) fall within the T1678 detection scope.
- Inventory the Process Creation, Module Load and Script Execution telemetry that is already available in your SIEM.
- Record the ATT&CK version the detections will target, so mappings stay correct when techniques are later revised.
How we build
- Write detection logic for delayed execution patterns in open formats such as Sigma, then translate it for your SIEM stack.
- Deploy and tune collection and rules in Wazuh or your chosen open-source platform, documenting each configuration change.
- Map detections to the ATT&CK mitigations relevant to T1678, including Audit and Behavior Prevention on Endpoint, where your tooling supports them.
How we hand over
- Deliver a validation report showing which benign and simulated test cases triggered each detection, and which did not.
- Provide a range runbook describing how your analysts rehearse T1678 detection and response in a private cyber range.
- Document known blind spots, tuning decisions and the owner responsible for maintaining each detection after handover.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing detection tuning, platform upgrades and repeat range exercises are available as a retainer.
- Confirm with DeployOpen during scoping which retainer terms and review cadence apply to your T1678 coverage.
