T1124 System Time Discovery: Detection, Mitigation and Response

System Time Discovery (T1124) is one of the quietest things an intruder does, and on its own it tells a defender almost nothing, but the moment it is followed by a scheduled task, a long sleep or a Kerberos request from an odd host it becomes a useful thread to pull. ATT&CK v20 lists T1124 under Discovery (TA0007) on Windows, Linux, macOS, ESXi and network devices, with more than 100 procedure examples from groups, malware families and campaigns. This page is for detection engineers and SOC analysts: why adversaries read the clock, which telemetry ATT&CK v20 points to, how to turn a near-useless single event into a correlated analytic, and the time hygiene that removes some of the value of the technique. Command names appear only at the level needed to write detection logic.

Key takeaways

• Low signal alone, useful in a chain. Administrators, management agents and almost every program read the time, so alerting on a single time query creates noise; ATT&CK v20's own detection strategy (DET0151) correlates the query with follow-on scheduling or conditional execution.
• Three adversary reasons dominate. Timing a payload (scheduled tasks, time bombs, delayed detonation), inferring the victim's locale from the time zone, and checking a host clock before Kerberos or time-sensitive operations.
• Remote time queries are rarer than local ones. A workstation asking another host or a domain controller for its time through net time or w32tm is unusual outside IT tooling and is the better hunting lead.
• ESXi and network devices count. ATT&CK v20 records UNC3886 collecting the system time on ESXi hosts, and network device CLI time queries are visible through AAA accounting and syslog.
• Good time hygiene is a control, not just plumbing. A single authoritative time hierarchy, a 5 minute Kerberos tolerance and alerting on time configuration changes support both detection and forensics.

What T1124 is and why adversaries use it

ATT&CK describes System Time Discovery as gathering the system time or time zone settings from a local or remote system. On Windows the time is kept by the Windows Time service (W32Time), on macOS by systemsetup and on Linux by the kernel clock and tools such as timedatectl. Domain-joined Windows computers synchronise through a domain hierarchy of time sources, with the PDC emulator of the forest root domain syncing to an external source, according to Microsoft's Windows Time service documentation. The technique has no sub-techniques in v20.

The ATT&CK description names several follow-on uses, and they shape what is worth detecting:

• Scheduling execution: knowing the local time lets an operator create a Scheduled Task/Job (T1053) that runs out of hours, or delay a payload until a set date (a time bomb).
• Victim profiling: the time zone helps infer location, which links T1124 to System Location Discovery (T1614). CISA advisory AA24-038A records that Volt Typhoon obtained the victim's system time zone and, separately, its current locale.
• Sandbox and analysis evasion: uptime and tick counts (for example the GetTickCount API) reveal freshly booted analysis machines. ATT&CK models this side as Time Based Checks (T1497.003), a separate ID with its own page.
• Kerberos and time-sensitive operations: Kerberos rejects requests when the client clock is too far from the domain controller (Microsoft's default tolerance is 5 minutes), so an operator working from a host outside the domain time hierarchy needs to know, and match, the domain controller's time before requesting tickets. CISA AA24-038A lists net time /dom among commands observed in Volt Typhoon activity as potentially used for reconnaissance or to manipulate system time.
• Implant registration: malware often sends the host time with its first beacon, which ATT&CK records for ZIRCONIUM and a Lazarus Group implant.

Real cases from ATT&CK v20

The procedure examples show how ordinary the technique looks in practice. Each row is taken from the ATT&CK v20 data and its cited report.

See the Volt Typhoon Threat Actor Profile for the wider living-off-the-land pattern behind the first row.

What to detect and where

ATT&CK v20 attaches detection strategy DET0151 to T1124, with one analytic per platform. Each analytic pairs a time query by an unusual process or user with a follow-on action inside a short correlation window (the strategy suggests 5 to 15 minutes on Windows and 5 to 20 minutes on Linux).

Tuning the analytic

• Allow-list by parent, not by command: the v20 analytic lists AllowedParents and ProcessPrevalenceThreshold as tunable elements. Exclude configuration management agents, monitoring tools and login scripts by parent image and signer, then alert on the rare remainder.
• Weight remote queries higher: a time query that names another host or the domain (net time with a target, w32tm /stripchart /computer, w32tm /monitor) from a non-IT workstation deserves more weight than a local one.
• Scope by user context: v20 suggests focusing on newly created, rare or non-administrative users. On Linux, ignore root-owned maintenance jobs and look at interactive or new users.
• Treat syscall auditing with care: auditing time(), clock_gettime and gettimeofday on Linux can be performance-sensitive, as the v20 analytic notes. Limit it to high-value hosts or rely on EDR instead.
• Fold it into a discovery burst score: T1124 is most useful as one point in a cluster with System Information Discovery (T1082), Account Discovery (T1087) and Remote System Discovery (T1018) run by the same session in a short period.

Where identity fits

Time matters to authentication. Microsoft documents the Kerberos policy "Maximum tolerance for computer clock synchronization" (Computer Configuration\Windows Settings\Security Settings\Account Policies\Kerberos Policy) with a default of 5 minutes and recommends keeping it there, because Kerberos timestamps prevent replay. Two detection angles follow:

• Time queries to domain controllers from unexpected hosts: a non-domain or newly seen host that queries DC time and then requests Kerberos tickets is worth correlating with ticket activity covered in the MITRE ATT&CK T1558 Steal or Forge Kerberos Tickets Guide.
• Service accounts reading the clock interactively: service and automation accounts call time APIs constantly from their normal binaries, but a service account launching a shell that runs time commands is a behaviour change. Baseline non-human identities by parent process and host, as described in the Kerberos Security Guide.

Mitigations and time hygiene

ATT&CK v20 maps no mitigation to T1124: reading the clock is a normal system function that cannot be blocked without breaking software. The controls below are NHI Mgmt Group recommendations that reduce the value of the technique and make the follow-on steps visible.

1. Enforce one time hierarchy. Keep domain members on the domain hierarchy (time client type NT5DS) and point the forest root PDC emulator at authenticated or trusted external sources. Microsoft documents w32tm /query /source and /query /configuration for checking this. See the NTP Security Guide.
2. Keep the Kerberos tolerance at 5 minutes. Raising it to paper over clock drift widens the replay window. Fix the drift instead.
3. Log time changes. Windows logs a system time change as Security event 4616; W32Time can also log time jumps and source changes through its EventLogFlags setting. Alert on time changes outside the time service, which also protects the integrity of log timestamps (NIST SP 800-53 AU-8).
4. Harden scheduling, the real payoff. Restrict who can create scheduled tasks, cron jobs and launchd items and alert on new ones from rare parents. See the T1053 Scheduled Task/Job Defensive Guide.
5. Bring hypervisors and network devices into scope. Forward ESXi shell, hostd and vpxa logs and network device AAA accounting to the SIEM so the ESXi and network device analytics have data.

How to test the detection

1. Baseline first: run a 14 to 30 day query of time-related process and command events grouped by parent, user and host to build the allow-list before alerting.
2. Emulate in a lab or approved test ring: run a local time query, a remote time query and a time zone query from a standard user, then create a scheduled task within the correlation window. Use an established, authorised emulation framework mapped to T1124 rather than custom scripts.
3. Confirm each log source: check that 4688 with command line, PowerShell 4104, TaskScheduler 106 and the Linux auditd rules actually arrive in the SIEM with the fields the rule uses.
4. Measure and roll back: run the correlated rule in report-only mode for two weeks, record the alert rate, then promote it. If volume spikes after an agent update, roll the rule back to report-only and widen the parent allow-list rather than deleting it.

Useful measures: correlated T1124 to scheduling alerts per week, true positive rate of those alerts, share of Windows endpoints sending command line and script block telemetry, number of hosts drifting more than 60 seconds from the domain hierarchy, and number of unexplained time change events (4616) per month.

Common failure patterns

• Alerting on every net time or date command: analysts learn to ignore the rule within a week. Correlate or do not alert.
• Process creation only: PowerShell cmdlets, .NET calls and API reads leave no new process, so cases like Kimsuky's Get-Date are missed without script block logging or EDR API telemetry.
• No hypervisor or network device logs: the ESXi and network device analytics are empty because the logs never reach the SIEM.
• Drift tolerated by raising Kerberos skew: the clock problem is hidden and the replay window grows.
• Unsynchronised log sources: when hosts disagree on the time, the 5 to 15 minute correlation window fails and incident timelines become unreliable.

Related discovery techniques: T1082 System Information Discovery, T1614 System Location Discovery and T1018 Remote System Discovery.

Framework mapping

Practitioner checklist

• Enable process creation with command line (4688) and PowerShell script block logging (4104) on Windows endpoints and servers.
• Build a parent process allow-list for time queries from 14 to 30 days of data.
• Deploy a correlated rule: time query by rare parent or user, then scheduled task, cron, launchd or long sleep within 15 minutes.
• Give remote time queries against other hosts or domain controllers a higher score than local ones.
• Forward ESXi shell, hostd and vpxa logs and network device AAA accounting to the SIEM.
• Confirm the domain time hierarchy and keep the Kerberos clock tolerance at 5 minutes.
• Alert on system time changes (4616) not made by the time service.
• Add T1124 to the discovery burst score with T1082, T1087 and T1018.

Standards and references

• MITRE ATT&CK: T1124 System Time Discovery
• MITRE ATT&CK: TA0007 Discovery
• CISA: AA24-038A PRC State-Sponsored Actors Compromise and Maintain Persistent Access to U.S. Critical Infrastructure
• Microsoft Learn: Windows Time service tools and settings
• Microsoft Learn: Maximum tolerance for computer clock synchronization
• MITRE ATT&CK: UNC3886 (G1048)
• NIST: SP 800-53 Rev 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Discovery and Reconnaissance Techniques Guide · T1053 Scheduled Task/Job Defensive Guide · MITRE ATT&CK T1497 Virtualization/Sandbox Evasion · NTP Security Guide · Windows Event Log Guide