T1497.003 Time Based Checks in MITRE ATT&CK Explained

Sıla Özeren Hacıoğlu | 7 MIN READ

| February 25, 2026

What Is T1497.003 Time Based Checks in MITRE ATT&CK?

T1497.003 Time Based Checks is a sub-technique of Virtualization and Sandbox Evasion (T1497) in the MITRE ATT&CK framework. It describes a sandbox evasion method where adversaries rely on time-related system characteristics to determine whether malware is executing on a real host or within an automated analysis environment.

Instead of inspecting system artifacts or user interaction patterns, attackers evaluate signals such as system uptime, clock values, and how time progresses. These indicators can reveal analysis environments that are short-lived or manipulate time to accelerate malware execution and inspection.

To read about other sub-techniques of the T1497 Virtualization and Sandbox Evasion technique, you can visit the related hub blog.

Adversary Use of T1497.003 Time Based Checks

Adversaries use Time Based Checks to avoid detection by sandbox or virtual environments. Malware implementing time based checks often introduces intentional execution delays, using sleep functions, timer loops, or prolonged benign operations to outlast the limited runtime of sandbox tools. In some cases, the code repeatedly invokes timing-related APIs or looped operations to verify whether elapsed time aligns with real-world expectations or exposes accelerated time behavior commonly used by analysis platforms.

If the observed time behavior deviates from what would be expected on a physical system, the malware may delay, modify, or suppress malicious activity, allowing it to evade detection and remain dormant until it reaches a trusted environment, thereby extending its operational lifespan.

Procedure Examples Used by Adversaries in Red Report 2026

After two consecutive years in which it did not appear in the Top 10 (2024 and 2025), the Virtualization and Sandbox Evasion technique reemerged in Red Report 2026 as one of the most commonly used techniques.

One observed procedure comes from the analysis of Blitz malware, which employs a timing-based anti-sandbox check similar to the System Checks sub-technique. Blitz has been observed using execution-time comparisons to identify virtualized environments [1].

Specifically, the malware measures the execution time of defined operations, such as 1,000,000 loop iterations, and compares results between the main thread and a secondary floating-point operation thread to detect abnormal timing behavior.

Main thread with CPUID loop

Thread

Purpose

Instruction Used

Main Thread

Acts as the timing loop.

CPUID. This instruction is typically executed quickly on physical hardware but can be intercepted and take longer in a VM, introducing measurable timing differences.

Second Thread

Performs a high number of floating-point calculations.

fyl2xp1 (a floating-point instruction). The variable global_count is incremented with each successful execution of this loop.

The malware runs the main thread for a fixed number of iterations (count = 1000000). The CPUID instruction in the main thread is used for "busy-waiting" and synchronization. While the main thread is running, the secondary thread is busy executing the floating-point instruction, repeatedly incrementing the global_count variable.

bool anti_sandbox() {
// [COLLAPSED LOCAL DECLARATIONS. PRESS NUMPAD "+" TO EXPAND]
thread_sig = 1;
global_count = 0;
hThread = CreateThread(0LL, 0LL, floating_point_thread, 0LL, 0LL);
count = 1000000;
hThread_2 = hThread;

do {
hThread_3 = hThread;
hThread_4 = hThread_2;
count_2 = count;
RAX = 0LL;
__asm { cpuid }
hThread_2 = hThread_4;
hThread = hThread_3;
count = count_2 - 1;
} while ( count_2 != 1 );

WaitForSingleObject(hThread_4, INFINITE);
resultant = (10 * global_count) / 1000000.0;
global_count *= 10;
return resultant > 5.0;
}

Second thread with floating point loop

int64_t __fastcall floating_point_thread(LPVOID lpThreadParameter) {
// [COLLAPSED LOCAL DECLARATIONS. PRESS NUMPAD "+" TO EXPAND]
for ( ; thread_sig; ++global_count ) {
v1 = 10;
do {
__asm { fyl2xp1 }
--v1;
} while ( v1 );
}
return 0LL;
}

After the main loop finishes, the result is calculated:

resultant = 1000000.010 × global_count​

The resultant value represents a ratio or measure of how many floating-point operations the secondary thread completed relative to the main thread's loop iterations.

The program then evaluates the expression: return resultant > 5.0.

  • If the system is a real, non-virtualized environment, the threads execute at a certain rate, and the resultant value is likely to be greater than 5.0.
  • If the system is a virtual machine or sandbox, the hypervisor (the VM software) can introduce overhead or inconsistencies in how it handles the concurrent execution of CPUID and floating-point operations. This slows down the secondary thread's ability to increment global_count, causing the final calculated resultant to be less than 5.0, which signals a detection of a virtual environment.

If the check confirms it's running within a VM, the malware terminates or displays a fake error message.

Procedure Examples Used by Adversaries in Red Report 2023

Adversaries may assess system uptime to determine whether malware is running in a virtualized or sandboxed environment. One common approach involves querying the “System Up Time” counter through the Windows Performance Data Helper (PDH) library. If the reported uptime is significantly shorter than expected, the malware may infer that it is executing in an analysis environment and either halt execution or alter its behavior.

To calculate uptime, adversaries frequently rely on the GetTickCount() function.

Note: The GetTickCount() function in Windows starts counting after the system has booted up. Malware can use this function to determine how long the system has been running and obtain a time value for each time stamp counter cycle.

For instance, according to a July malware* analysis report published by CISA, adversaries are still using the GetTickCount() to check if the malware is running in a virtual environment [2].

* 66966ceae7e3a8aace6c27183067d861f9d7267aed30473a95168c3fe19f2c16

Qbot payload includes an anti-debug check characteristic using the GetTickCount() API [3].

An analysis of packed* and unpacked** IcedID samples show that the malware is also leveraging the GetTickCount() function [4].

*(MD5) 157d12885e5f6434436862aadd6224cd

**(MD5) 578143ef946796590c0dd5f5dcfdada7

  • Delayed Execution

In addition to utilizing uptime, malware developers may use various techniques to delay the execution of malicious activities in order to evade detection in virtual machine (VM) or sandbox environments.

For example, sleep evasion is a common trick that we see in malware. For instance, adversaries may leverage a trojan that calls the SleepEx() method with a timeout parameter of 10 minutes before they perform any malicious activities or run a payload. There are many functions that adversaries can perform sleep evasion:

  • Sleep()
  • WaitForSingleObject()
  • WaitForMultipleObjects()
  • WaitForSingleObjectEx()
  • WaitForMultipleObjectsEx()

2022 was another year in which those adversaries commonly leveraged time-based evasion techniques in the wild. For instance, analysis of a destructive malware called WhisperGate shows that adversaries are leveraging the following PowerShell command to evade the Anti Virus (AV) [5]:

powershell -enc UwB0AGEAcgB0AC0AUwBsAGUAZQBwACAALQBzACAAMQAwAA==--> Start-Sleep -s 10

Note that the Start-Sleep cmdlet is used to suspend the activity for 10 seconds. To make it sleep for 20 seconds, they run the command twice.

Bumblebee malware has also been detected to be using the SleepEx() function.

. . .
ModuleHandleA = GetModuleHandleA("kerne132.dll");
*&shellcode[21] = GetProcAddress (ModuleHandleA, "SleepEx");
entrypoint_from_proc = get_entrypoint_from_process (hProcess);
WriteProcessMemory = GetProcAddress (ModuleHandleA, "WriteProcessMemory");
VirtualProtectEx(hProcess, entrypoint_from_proc, 33ui64, 0x40u, &flOldProtect);
result = (WriteProcessMemory) (hProcess, entrypoint_from_proc, shellcode, 33i64, &v8);
. . .

Briefly, the shellcode is injected into the suspended process and the initial entry point is being replaced with a new function, SleepEx [6].

StrifeWater RAT, a new Trojan mainly used by an Iranian APT group called Moses Staff, is known for updating the sleep time responses of the malware for 20-22 seconds (as a default) [7].

SaintBot.NET loader, which was mainly used in spear phishing attacks targeting organizational entities in Ukraine, also uses time-based evasion techniques [8].

internal static class Class6 {
internal static void smethod() {
Process process = new Process();
process.StartInfo.FileName = "powershell";
process.StartInfo.Arguments = " -enc YwBtAGQAIAAVAGMAIABOAGKAbQB1AGBAdQBOACAAMgAWAA==";
process.StartInfo.WindowStyle = ProcessWindowStyle.Hidden;
process.Start();
process.WaitforExit(); } }

In the above code, the loader It begins by running a single PowerShell command that causes the execution of the cmd.exe program with the argument timeout 20. This causes a delay of 20 seconds before the loader will continue its execution.

Validate Your Defenses Against the Red Report 2026 Threats

 

References

[1] D. Reichel, "Blitz Malware: A Tale of Game Cheats and Code Repositories," Unit 42, Jun. 06, 2025. Available: https://unit42.paloaltonetworks.com/blitz-malware-2025/. [Accessed: Dec. 09, 2025]

[2] “MAR-10382580-r2.v1 – RAT.” [Online]. Available: https://www.cisa.gov/uscert/ncas/analysis-reports/ar22-197a. [Accessed: Dec. 30, 2022]

[3] Uptycs Threat Research, “Qbot Reappears, Now Leveraging DLL Side Loading Technique To Bypass Detection Mechanisms,” Jul. 28, 2022. [Online]. Available: https://www.uptycs.com/blog/qbot-reappears-now-leveraging-dll-side-loading-technique-to-bypass-detection-mechanisms. [Accessed: Dec. 30, 2022]

[4] “eSentire Threat Intelligence Malware Analysis: Gootloader and IcedID,” eSentire, Jul. 18, 2022. [Online]. Available: https://www.esentire.com/blog/esentire-threat-intelligence-malware-analysis-gootloader-and-icedid. [Accessed: Dec. 30, 2022]

[5] S2W, “Analysis of Destructive Malware (WhisperGate) targeting Ukraine,” S2W BLOG, Jan. 18, 2022. [Online]. Available: https://medium.com/s2wblog/analysis-of-destructive-malware-whispergate-targeting-ukraine-9d5d158f19f3. [Accessed: Dec. 30, 2022]

[6] “This isn’t Optimus Prime's Bumblebee but it's Still Transforming,” Proofpoint, Apr. 27, 2022. [Online]. Available: https://www.proofpoint.com/us/blog/threat-insight/bumblebee-is-still-transforming. [Accessed: Dec. 14, 2022]

[7] C. Nocturnus, “StrifeWater RAT: Iranian APT Moses Staff Adds New Trojan to Ransomware Operations.” [Online]. Available: https://www.cybereason.com/blog/research/strifewater-rat-iranian-apt-moses-staff-adds-new-trojan-to-ransomware-operations. [Accessed: Dec. 30, 2022]

[8] Unit, “Spear Phishing Attacks Target Organizations in Ukraine, Payloads Include the Document Stealer OutSteel and the Downloader SaintBot,” Unit 42, Feb. 25, 2022. [Online]. Available: https://unit42.paloaltonetworks.com/ukraine-targeted-outsteel-saintbot/. [Accessed: Dec. 15, 2022]

Table of Contents

Ready to start? Request a demo