Why T1124 system time discovery matters to your SOC
T1124 System time discovery describes an adversary querying a host or device for its system time, usually to learn whether it is a useful target and how it fits the environment around it. Within the Discovery tactic (TA0007), ATT&CK frames the goal as figuring out the environment, and time is one of the simplest pieces of that picture: it reveals the host's clock setting, its time zone and sometimes how it is synchronized to other systems. The query is cheap, quiet and almost always legitimate in isolation, which is exactly why a SOC can see it in volume and struggle to decide whether it matters. In intrusions, time queries tend to appear early, during reconnaissance shortly after an adversary gains a foothold on a host or device. They are often bundled with other discovery activity, such as checking the operating system, network configuration, running processes or local accounts, so the signal is better read as a cluster than as a single event. For that reason, the practical question for your analysts is not whether a time command ran but whether it ran alongside other discovery actions from an unexpected account, parent process or host role. Confirm with your own baseline which administrative and monitoring tools routinely query time on each platform, since those are the main sources of benign noise. The version you target matters when you write or tune these detections. This page maps to Enterprise ATT&CK v20.0, and your detection mappings should name that version explicitly, because releases can rename, deprecate or revoke techniques and their detection guidance. Before you commit a rule to production, check the technique and its data components against the version you are running in your own catalog, and record that version alongside the rule so that later reviews can tell whether the coverage still matches the framework.
Which telemetry reveals system time discovery
This table maps the data components Process Creation (DC0032), Command Execution (DC0064) and OS API Execution (DC0021) to the signal each gives for T1124 across ESXi, Linux, macOS and network devices, and names an open-source collector for each. Read each row as a starting point: the signal is usually present, but whether it is captured depends on logging configuration that you must confirm in your own environment.
| Telemetry source | What it reveals for T1124 | Open-source collection path |
|---|---|---|
| Process Creation (DC0032) on Linux | Execution of time-query utilities or scripts that read the system clock, recorded with parent process and user context | Wazuh agent with auditd execve rules, or Auditd directly; confirm the rule set captures process arguments on your hosts |
| Process Creation (DC0032) on macOS | Launches of built-in time utilities by unexpected parents, such as scripts or non-administrative user processes | Wazuh agent and unified log forwarding, or an Endpoint Security based collector; confirm process argument visibility on your macOS version |
| Command Execution (DC0064) on Linux and macOS | Shell command lines that invoke time or date queries, including from interactive sessions and scheduled jobs | Shell history forwarding and auditd command capture via Wazuh; confirm that shell history is not disabled on sensitive hosts |
| OS API Execution (DC0021) on Linux and macOS | Calls to clock-reading functions made by processes that do not normally need them; visibility is often limited without specialized tooling | Auditd or eBPF-based collectors where available; treat this as a gap to confirm rather than assume coverage |
| ESXi host logging | Shell or SSH sessions where time or host status commands are run, and host time configuration changes | Remote syslog from ESXi hosts to a Wazuh or Security Onion collector; confirm that ESXi shell and SSH access logging is enabled |
| Network device syslog | Administrative sessions on routers and switches where time or clock status is queried | Syslog forwarding to Wazuh or a SIEM collector; confirm that command accounting is enabled on each vendor platform |
| Zeek or Suricata network evidence | Network-side evidence is limited for T1124 because clock queries are usually local, but NTP traffic to unexpected destinations can support investigation | Zeek NTP analysis or Suricata rules for NTP flows; confirm whether NTP traffic is in scope for your monitoring |
Detection logic for system time queries that tune well
System time queries are cheap, common and often run by legitimate software, so the detection value comes from context rather than from the query itself. The cards below describe four detection ideas for T1124 System time discovery, the benign tooling that will trigger each one, and how to baseline each host group before setting thresholds.
Time utility execution by platform
Alert on process creation events for built-in time utilities, scoped separately for ESXi, Linux, macOS and network device management planes, since each platform exposes time through different binaries and shells. Set the threshold on first-seen or rare occurrences per host group rather than on any execution, because NTP clients, chrony or systemd time services, and configuration management runs will query time routinely. Baseline each group over a representative period, including patch windows, and document which agent accounts are expected to run these utilities.
Parent process and user context
A time query run by an interactive user shell, a web service account or a container entrypoint is more suspicious than the same query run by a known time synchronization daemon. Use parent process lineage and the executing user to separate expected callers from unexpected ones. False positives come from monitoring probes, backup agents and deployment pipelines that run inside shells, so allowlist by signed parent and service account only after reviewing those agents with their owners.
OS API time calls from unusual binaries
OS API Execution telemetry, where the platform provides it, can show time retrieval from processes that have no reason to read the clock, such as script interpreters or unsigned binaries in temporary directories. Tune by listing the binaries that legitimately call time APIs, which typically include database engines, logging frameworks, JVM and language runtimes. Confirm with each platform owner whether the telemetry source captures these calls at all before relying on it, because coverage varies by operating system and agent version.
Time queries in bursts with other discovery
A single time query carries little signal, but a short burst of time queries alongside other discovery techniques, such as system information or network configuration checks, on the same host is a stronger indicator. Correlate by host and time window across process creation and command execution events. Expect false positives from inventory scans, vulnerability scanners and configuration audits, so record their schedules and source hosts and suppress them by scan identity rather than by time alone.
How to validate the T1124 detection in a lab
This sequence proves that system time queries on each target platform produce logs, that the detection rule fires on them, and that the alert carries the fields an analyst needs. It also establishes a baseline for false positives and repeats the test after platform upgrades.
Fix the ATT&CK version and technique scope
Record the ATT&CK version the detection maps to, for example Enterprise ATT&CK 20.0, and confirm T1124 System Time Discovery is still present in that version's STIX bundle, since releases can rename, deprecate or revoke techniques. List every platform in scope, such as ESXi, Linux, macOS, network devices and other platforms, and name the owner of each. The step is done when the scope sheet is signed by the detection owner and the platform owners, and each platform has a named test host in the range.
Map expected telemetry for each platform
For each platform, document which data components the detection depends on, typically Process Creation, Command Execution and OS API Execution, and which log source or agent provides them. Note the expected event fields and the log path or API feed for each source. Confirm with the platform vendor or your own configuration which telemetry is native and which requires an audit policy or agent setting. The step is done when every platform has a telemetry map that the SIEM team has reviewed.
Plan a benign system time query emulation
Agree with the range team a benign emulation that performs routine system time queries on each test host, using only the approved and documented methods for that platform, under a written rules-of-engagement note. Record the start time, the host, the account used and the intended number of queries so results can be matched later. Do not publish exact commands in the lab runbook; keep the emulation plan in words and reference the approved tooling. The step is done when the plan is approved and the expected event trail is written next to it.
Confirm logs reach the SIEM
Run the emulation on one platform first and check that the raw events arrive in the SIEM, such as Wazuh or Security Onion, with timestamps, host identity and process or command context intact. Compare the received fields to the telemetry map from the earlier step and note any missing or renamed fields. Repeat for each platform. The step is done when every platform has at least one confirmed event in the SIEM with the expected fields, and any ingestion gaps have tickets assigned.
Check the rule fires as designed
Enable the Sigma or native rule for T1124 in a test scope and run the emulation again. Verify that the rule matches the events it was written for and produces an alert, and that it does not fire on unrelated events from the same host. Record the rule version and ATT&CK mapping that produced the alert. The step is done when each in-scope platform shows a fired alert tied to the rule version under test, and the mapping in the alert matches the ATT&CK version named in the scope.
Measure time to alert and populated fields
For each fired alert, record the time between the emulation event and the alert, along with the alert timestamp, host, user, process and any ATT&CK tags. Note which fields are empty or inconsistent across platforms. Compare results with the response target your team has agreed, without assuming a value that was not agreed. The step is done when a results table lists time to alert and field completeness for every platform, and gaps have an owner.
Record false positive outcomes and tune
Run the rule across a period of normal administrative activity in the range, including scheduled jobs, monitoring agents and configuration management, and log every alert that is not linked to the emulation. Classify each as a true positive, expected benign activity or an unexplained result, and tune the rule with a documented change. Confirm that the tuned rule still fires on the benign emulation. The step is done when the false positive log is reviewed and the rule change is versioned.
Retest after OS and agent upgrades
Treat every OS release, logging agent upgrade or SIEM content update as a trigger to rerun the emulation and the rule check on the affected platform. Compare the new results with the stored baseline for event volume, fields and time to alert. Also check that the ATT&CK version named in the scope is still the one you target after any framework update. The step is done when the retest record is filed against the change request and the baseline is updated or the regression is logged.
Preventive controls that reduce time-query exposure
System time queries are low-cost for an adversary and hard to block outright, so prevention focuses on what the query can reach and what gets logged. The four ATT&CK mitigations below shape the environment around the technique: how systems are configured, which features and tools exist on each host, how management traffic is segmented, and whether the resulting activity is recorded.
Operating system configuration (M1028)
M1028 covers hardening settings that remove unnecessary exposure from hosts. For T1124, the relevant question is which time sources, time synchronization services and remote management interfaces are reachable and by whom. Confirm that time synchronization points to approved internal or vetted sources, that the configuration is version-controlled, and that deviations are reported. Hosts with no legitimate reason to accept remote time or management queries should not expose them. Review this baseline on ESXi, Linux, macOS and network device images, since each platform stores time settings differently.
Audit (M1047)
M1047 concerns recording security-relevant activity so that enumeration can be seen after the fact. A time query by itself is common in administration, so the value lies in logging process creation and command execution with enough context to tell an administrator's routine check from an unexpected one. Confirm that audit policies capture the account, parent process and command line for commands that read or set system time, and that those logs are forwarded to a central platform such as Wazuh before local retention expires.
Disable or remove feature or program (M1042)
M1042 reduces the number of tools available on a system. Many hosts carry utilities that can display or report time without any operational need, and removing them narrows what an adversary can use without relying on tools they have brought. Build an inventory of time-related utilities and interpreters on each image, remove or restrict those not needed for operations, and record the exceptions. Expect some legitimate tooling to be required for time synchronization, so the list should be reviewed with platform owners rather than assumed.
Network segmentation (M1030)
M1030 limits which hosts can reach which others. Where time queries are issued against management planes, hypervisor hosts, network devices or cloud control endpoints, segmentation determines whether a compromised workstation can reach those targets at all. Confirm that management interfaces sit on a dedicated network, that only authorized administrative subnets can reach them, and that time source traffic follows documented paths. Test the boundary with a cyber range scenario so the segmentation claim is verified, not assumed.
How to triage and respond when the time discovery alert fires
Start by confirming what the alert actually saw. For T1124 System time discovery, the alert usually comes from a process creation or command execution event on ESXi, Linux, macOS or a network device that queried the system clock or time configuration. Record the host name, the logged-in or service account, the full command line, the parent process and the working directory. Then decide whether the process matches an approved job. Ask the platform owner and the change calendar whether a time synchronization check, a monitoring agent or a configuration management run was scheduled in that window. Time queries are routine for NTP clients, log correlation and certificate validation, so a benign match is common. Treat the alert as suspicious only when the account, parent process or host role does not fit the job that normally runs there.
Next, widen the window. Pull Discovery and lateral movement signals for the same host and account in the surrounding period, including file and directory enumeration, account listing, network connection queries, process listing and remote logon events. Time discovery alone rarely indicates intent, but it often appears as one step in a sequence that maps the environment before movement. Check whether the same account has authenticated to other hosts, whether new sessions or scheduled tasks appeared, and whether the host has recent configuration changes. If you find a cluster of such signals, escalate to the incident response lead with the timeline rather than a single alert. Confirm retention on each log source before you rely on it, because a short retention period can remove the context you need.
Containment should keep evidence intact. Isolate the host or restrict the account through network controls or access policy, not by rebooting or reimaging, which destroys volatile state. Before any change, preserve the relevant logs by exporting them to write-once storage and recording hashes, and capture memory or process details if your runbook allows it. Document the alert identifier and detection rule version, the ATT&CK technique ID T1124 and the ATT&CK version your mapping targets, the decisions made with timestamps, who approved each step, and the final classification. That record supports both the incident review and any later assessment of whether the detection behaved as designed.
Rehearsing T1124 detection in a private cyber range
A private cyber range for T1124 System Time Discovery needs targets that reflect the platforms where the technique is commonly observed in your estate: ESXi hosts, Linux servers, macOS endpoints and at least one network device. The range should be isolated from production networks and from the internet, and every target should forward its telemetry to a single collector such as Wazuh or Security Onion so the team can compare what each platform records. The illustrative layout below is a starting point, not a fixed design.
- Hypervisor target: An ESXi host or nested lab host with its management logs forwarded to the collector, so the team can confirm which time-related commands and management actions are visible.
- Linux and macOS endpoints: Hosts with process auditing and command logging enabled, so process creation and command execution telemetry can be compared across the two operating systems.
- Network device target: A device or emulated device sending syslog to the collector, with a documented check of which time-related queries it logs.
- Collector: Wazuh or Security Onion, with time synchronization verified on every source so that event timestamps can be correlated during review.
Confirm with each vendor which logging features your versions support, and record the exact configuration used so the exercise can be repeated.
The inject schedule defines which benign activities the red or purple team performs, in what order, and when the blue team is expected to see them. Benign activity matters because it establishes the baseline that detection rules must separate from suspicious use. Each inject should be written down with its purpose, target platform and expected telemetry before the exercise starts, so the team can judge results against a plan rather than memory.
- Baseline period: Normal administrative activity, including scheduled jobs and time synchronization services, recorded before any injects run.
- Benign injects: Routine checks of system time performed by administrators and monitoring agents, so analysts learn what legitimate use looks like on each platform.
- Suspicious-pattern injects: Time-related queries run in unusual sequence or by unexpected accounts, mapped to the detection strategy the team is testing.
- Pacing and deconfliction: A clear start and stop record for each inject, so analysts can tie alerts to specific activities.
Agree the schedule, the observers and the stop conditions in writing with the client before any activity begins.
Good detection and response for T1124 is defined by outcomes the team records, not by the presence of a dashboard. Each inject should produce a known result: an alert, a logged event with the expected fields, or a documented gap. Measure these outcomes for every platform so that weaknesses are visible rather than assumed. Record results against the ATT&CK version and detection strategy identifiers the team targets, because technique content can change between releases.
- Telemetry presence: Whether process creation and command execution events appear on each platform for each inject, with timestamps that line up across sources.
- Alert fidelity: Whether the detection fired for suspicious-pattern injects and stayed quiet for benign injects, with the false positive and false negative counts recorded.
- Time to triage: The interval between the inject and the analyst's documented triage decision, measured from the collector's timestamps.
- Response actions: Whether the playbook steps were followed, including evidence preservation and escalation to the right owner.
Review the measured outcomes with the client's security lead before setting any target for the next exercise.
The after-action review turns exercise results into changes in detection content, logging configuration and playbooks. It should happen soon after the exercise while analysts still remember the sequence of events. The review should be blameless and focused on evidence, with every finding linked to a specific inject, log source or rule. Findings that cannot be reproduced should be marked as unverified rather than closed.
- Evidence walkthrough: A timeline built from collector data, checked against the inject schedule, so the team agrees on what happened and when.
- Gap register: Each missing log source, unclear alert or slow handoff recorded with an owner and a retest plan.
- Rule and configuration changes: Updates to detection logic, tuning and logging settings, versioned and tested in the range before production.
- Retest: A repeat of the affected injects after changes, confirming the fix works and does not create new noise.
Confirm with your auditors or compliance leads which review records they expect to see as evidence.
Questions SOC leads ask about detecting T1124
How do we separate administrator time checks from adversary system time discovery?
Treat the command itself as weak evidence and the context around it as strong evidence. Administrators check time during patching, certificate troubleshooting, log correlation and NTP fixes, so a single invocation of a time query is rarely meaningful on its own. Build a baseline per host group and per account, then alert on time queries that come from unexpected parent processes, from service accounts that never run interactive work, or that cluster with other Discovery activity such as account, network or process enumeration within a short window. Document the approved administrative workflows so analysts can suppress known-good patterns with a written justification rather than by broad exclusions.
Which platforms need extra logging before T1124 detection works?
Linux and macOS hosts usually need process execution auditing enabled, because time queries often run as ordinary commands that are invisible without it. ESXi hosts, network devices and other appliances may expose time information only through management interfaces, so confirm which of their logs record command execution and administrative sessions. Confirm with each vendor what its logs contain and how long they are retained, since the ATT&CK data components referenced for this technique (Process Creation, Command Execution and OS API Execution) are only useful where the platform actually emits them. Test each platform in a lab before assuming coverage exists.
How should we handle ATT&CK version changes that affect this technique?
Record the ATT&CK version your detections target in every rule, and review that mapping whenever MITRE publishes a release. ATT&CK v18 (October 28, 2025) replaced technique-level detections with detection strategies and analytics and changed data components, and MITRE notes that releases can rename, deprecate or revoke techniques. Keep a mapping table that links each Sigma rule or Wazuh decoder to its detection strategy identifier and data component, and check the release notes for changes before each upgrade. This keeps coverage reports honest when the framework moves under your content.
Does network-side detection add value for system time discovery?
Network telemetry adds limited but useful signal for this technique, mainly where time is queried from remote systems or where management protocols carry time information in clear text. A host-side command is far more direct evidence, so network detection should complement endpoint logging rather than replace it. Zeek or Suricata sessions can show which hosts query time services across segments, which helps when an adversary moves between systems and host logs are incomplete. Verify with your own traffic that the relevant protocols are visible at your sensor placement before relying on them.
How often should we re-run validation for T1124 detections?
Re-run validation whenever the detection content changes, after each platform upgrade that touches logging or audit configuration, and on a fixed schedule set by your risk owner. Many teams tie the schedule to the ATT&CK release cycle plus any major change to endpoint agents or log forwarding, because a silent logging change is the most common reason a working rule stops firing. Keep the validation results with the rule so auditors and incident responders can see when the detection last worked. The right frequency depends on your change rate, so agree it in writing with the owners of each platform.
How do we measure T1124 detection quality without relying on vendor claims?
Measure the detection with your own test results and your own alert outcomes, not with a vendor's coverage percentage. Useful measures include whether a controlled, documented time query in each platform produces an alert within your target window, the false positive rate per host group over a defined period, and the proportion of alerts that analysts close with a documented reason. Track these in a simple register tied to the ATT&CK version and detection strategy identifier. Ask any vendor or partner to show how their metrics are calculated and what test conditions they used before accepting them.
Can our own team run T1124 detection exercises in a private cyber range?
Yes, a team with Linux, Wazuh or Security Onion experience can rehearse this detection in a private range without outside help, provided the range is isolated and the exercise rules are written down. DeployOpen builds and supports self-hosted ranges inside a client's own infrastructure, and runs security testing and training, so an external partner can help set up the environment or design the exercises. Decide early which parts your team owns, such as rule tuning and response playbooks, and which parts you want to scope in a fixed-scope written agreement. Ask any partner to confirm exactly what is covered and what remains with your staff.
How DeployOpen builds T1124 detections and range scenarios
DeployOpen starts every T1124 engagement by fixing the scope in writing before any detection content is written. The scope names the platforms where System Time Discovery matters for the client, such as ESXi hosts, Linux and macOS endpoints, and network devices, and it names the ATT&CK version the mapping targets. Because MITRE can rename, deprecate or revoke techniques between releases, the mapping records a specific Enterprise ATT&CK version, and the team confirms that version against the current MITRE ATT&CK updates before rules are tested. The client decides which platforms are in scope, which log sources are actually collected, and who owns the tuning decisions afterward.
On the detection side, the work is written as open-source content for the client's own SIEM, typically Wazuh, Security Onion or a Sigma-based pipeline, depending on what the client already runs. The team maps each rule to the data components that ATT&CK references for this technique, such as Process Creation, Command Execution and OS API Execution, and then checks whether the client's agents and collectors actually emit those events on each platform. Gaps are reported as gaps, with the specific host groups and log paths that need configuration changes. Rules are documented with their logic in plain language, their known benign sources, and the owner who approves changes.
Validation happens in a private cyber range that mirrors the client's platform mix. DeployOpen plans purple team exercises in which the client's defenders and the testers agree in advance on the time discovery activity to be simulated, the expected alerts and the response steps. Results are recorded per platform: which detections fired, which did not, how long triage took and which tuning changes followed. The resulting validation evidence, including rule versions, test records and tuning history, is handed over to the client so their own team can repeat the exercise. DeployOpen prepares this evidence for compliance assessments, but it does not issue audit reports or attestations, which remain the role of independent auditors. Ask any provider to state the deliverables, scope boundaries and acceptance criteria in the written scope before work starts.
