DET0141: Detect Time-Based Evasion via Sleep, Timer Loops, and Delayed Execution
DET0141 is a MITRE detection strategy for spotting time-based evasion, where software delays execution or checks time behavior to decide whether it is bein...
Analyst context for executives and security teams
DET0141 is a MITRE detection strategy for spotting time-based evasion, where software delays execution or checks time behavior to decide whether it is being analyzed. The business issue is not the sleep call itself; it is that sandbox, SOC, and incident-response workflows can miss or misclassify suspicious activity if analysis windows are too short or telemetry does not preserve delayed behavior context.
Executive priority
Treat this as a validation topic for malware analysis, managed detection, and incident-response readiness. Leaders should ask whether security tooling can observe long-running or delayed execution patterns, whether sandbox results are treated as inconclusive when timing behavior is present, and whether audit or incident evidence captures process behavior over enough time to support decisions. Priority is highest where Windows, Linux, or macOS endpoint visibility is material to resilience, based on the related ATT&CK technique T1497.003.
Technical view
The supplied ATT&CK object has no official description, platform list, tactic list, or detection text, but it is related to T1497.003 Time Based Checks, which is associated with stealth and discovery on Linux, macOS, and Windows. SOC and detection teams should validate whether endpoint, sandbox, and analysis pipelines preserve evidence of sleep, timer loops, delayed execution, uptime/system-clock inspection, and API or system calls such as GetTickCount and GetSystemTimeAsFileTime where applicable. IR teams should avoid treating lack of immediate malicious action as benign when a sample or process shows timing-aware behavior.
Likely telemetry
- Endpoint process execution and parent-child process context
- API or system-call telemetry related to timers, sleep, uptime, and system clock inspection where available
- Sandbox or detonation logs, including elapsed analysis time and delayed behavior observations
- EDR behavioral timelines showing long gaps between process start and later activity
- Host event logs or sensor data that can correlate process lifetime, command execution, and subsequent network or file activity
Detection direction
- Validate that sandbox and automated analysis durations are long enough, or that results are flagged as limited when delayed execution is observed.
- Correlate timing behavior with later suspicious actions rather than alerting on sleep or timer use alone, since legitimate software commonly uses timers and delays.
- Look for repeated timing checks, uptime or clock queries, or execution gaps that occur before discovery, network, file, or payload activity.
- Tune detections to reduce false positives from installers, updaters, scheduled tasks, and normal application wait loops.
- Use the relationship to T1497.003 as context: coverage should be tested against stealth and discovery behaviors across Linux, macOS, and Windows environments where those platforms are in scope.
Mitigation priorities
- Prioritize endpoint and sandbox visibility that records process timelines and delayed behavior, not only initial execution verdicts.
- Extend or vary malware-analysis run times for suspicious samples when timing behavior is present.
- Document when analysis results are inconclusive due to potential time-based evasion so incident decisions do not rely on a false sense of safety.
- Review SOC playbooks to ensure delayed execution and time checks trigger deeper triage rather than immediate closure.
- Use detection testing to confirm telemetry retention, correlation windows, and analyst workflows support time-based evasion scenarios.
Analyst notes and limits
This take is based on a detection-strategy object with sparse official fields and one relationship: it detects ATT&CK technique T1497.003 Time Based Checks. The relationship provides the relevant behavioral context: adversaries may use time-based properties, uptime, system clock, or calls such as GetTickCount and GetSystemTimeAsFileTime to detect virtualization or analysis environments.
The object provides no official description, no official detection text, no direct platforms, and no tactics. Platform and tactic context comes only from the related T1497.003 technique. Local telemetry, tool configuration, sandbox duration, and endpoint coverage must be verified before making coverage claims.
Detect Time-Based Evasion via Sleep, Timer Loops, and Delayed Execution
No official description is available in the imported ATT&CK source object.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1497.003 | Time Based Checks Sub-technique | This object detects Time Based Checks. |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 383707b32cee… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DET0141Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.