System time discovery activity

Threat snapshot

System time discovery is rarely what it appears to be. On the surface, querying the current date and time on a Windows system is a trivial, routine operation. Hundreds of legitimate applications do it constantly. But when an attacker who has gained a foothold on an endpoint queries the system time, they are almost never checking the clock for convenience. They are gathering intelligence about the environment: validating that their tools will function correctly, checking whether a time-sensitive payload is within its activation window, determining the local time zone to coordinate with a remote C2 operator, or confirming that log timestamps will match expected patterns if they need to forge or manipulate records.

System time discovery is documented in the MITRE ATT&CK framework as a reconnaissance technique used during the discovery phase of an intrusion, frequently appearing in the early post-exploitation activity of commodity malware, ransomware operators, and targeted threat actors alike. Log360 detects it through the System Time Discovery Identified rule, which monitors for the specific commands and APIs used to query system time in contexts that are anomalous for the affected host. The value of this detection is not in the time query itself, but in what it tells the SOC about the stage of the intrusion and what is likely to follow.

At a glance

How this attack works

Attackers use several methods to query system time on Windows endpoints, each leaving a different telemetry footprint. The most common are:

• Command-line queries: running net time, w32tm /query /status, or time /t from cmd.exe or PowerShell. These are the most easily detectable because they generate a process creation event with a visible command-line argument.
• WMI queries: calling Win32_LocalTime or Win32_TimeZone via PowerShell's Get-WmiObject or Get-CimInstance. WMI-based time discovery is harder to detect because it does not spawn a child process and the query is embedded in a larger script.
• API calls: directly invoking GetSystemTime, GetLocalTime, or GetTimeZoneInformation from the Windows API via a compiled binary or an inline assembly call in a script. These leave no command-line trace and are only visible through Sysmon process access or API monitoring.

In the context of an active intrusion, system time discovery typically serves one of four operational purposes. First, time-based payload activation: some malware families, particularly ransomware, include logic that checks the current date or time before executing their main payload, either to avoid activating during known analysis windows or to synchronise deployment across multiple hosts. Second, C2 synchronisation: remote access tools that use time-based one-time authentication tokens or that schedule callbacks at specific intervals need to confirm the local system time before initiating contact. Third, log timestamp awareness: attackers who intend to manipulate or delete log entries need to know the current timestamp format and time zone to ensure their forgeries are consistent with surrounding legitimate events. Fourth, environment fingerprinting: automated implants that perform broad post-exploitation discovery routinely include system time as one of dozens of environmental data points collected and reported back to the operator.

Attack chain

The table below maps system time discovery to its position in a typical intrusion sequence and its corresponding MITRE ATT&CK technique.

Real-world scenario

A logistics company with offices across four time zones uses a standard Windows endpoint build. A threat actor who gained access via a malicious macro in a shipping document has deployed a lightweight implant on a finance team member's workstation. The implant begins automated post-exploitation discovery within 60 seconds of execution.

Among the first commands the implant runs is w32tm /query /status, followed immediately by net time /domain, whoami /all, ipconfig /all, and net group "Domain Admins" /domain. The time queries serve two purposes for the attacker: confirming the local time zone so the C2 callback schedule can be adjusted to match local business hours, and determining when the nightly backup window runs so the ransomware payload can be timed to execute after the last backup completes but before the next one starts.

Without a rule specifically monitoring for system time discovery commands, these queries blend into background noise and the discovery sequence goes unnoticed. By the time the ransomware deploys three days later during the early morning backup window, the attacker has already exfiltrated 40 GB of financial records. The system time query was the first detectable signal of the post-exploitation phase, and it was the one that went unlogged.

Why this happens
System time commands are so common in legitimate administrative activity that security teams rarely configure alerts for them. The net time and w32tm commands appear in login scripts, monitoring tools, and scheduled tasks across almost every Windows environment. Without a rule that filters for these commands in anomalous contexts, specifically when run by unusual parent processes, by accounts with no history of running these commands, or in rapid succession with other discovery commands, the activity is indistinguishable from normal operations at a glance.

Business impact: What can go wrong

System time discovery on its own carries limited direct impact. Its significance is as an early indicator of a broader intrusion that, if not acted on, leads to more serious consequences:

• Missed intrusion indicator: system time discovery is one of the earliest detectable signals of post-exploitation activity. Failing to detect it means the SOC misses an opportunity to intervene before the attacker completes their reconnaissance and moves to higher-impact actions.
• Ransomware timing intelligence: attackers who query system time before deploying ransomware are using the information to time their attack for maximum damage, typically during off-hours or over weekends when response capacity is reduced and backup windows have just closed.
• Log manipulation preparation: an attacker who queries the system time before deleting or modifying log entries is preparing to ensure their forgeries are timestamp-consistent. Detecting the time query before the log manipulation occurs gives the SOC a window to preserve evidence.
• C2 scheduling: time zone confirmation allows attackers to adjust their remote access tool's callback schedule to match local business hours, making C2 traffic harder to distinguish from legitimate outbound connections by blending with the normal traffic pattern.
• Discovery chain visibility: the System Time Discovery rule is most valuable as a tripwire. When it fires alongside other discovery rule alerts in a short window, it indicates a systematic post-exploitation enumeration sequence that strongly implies an active, skilled threat actor rather than opportunistic malware.

Indicators of compromise and detection signals

Prerequisites for detection using Log360

Before the System Time Discovery Identified rule can fire reliably, ensure the following are in place:

• Windows Process Creation auditing is enabled with command-line logging active on all monitored endpoints, generating Event ID 4688 with the full ProcessCommandLine field populated. Without command-line logging, process creation events for net.exe and w32tm.exe will not include the arguments needed to distinguish time discovery from other uses of these binaries.
• Sysmon is deployed on endpoints with a configuration capturing Event ID 1 (Process Create) including the ParentImage and ParentCommandLine fields. Sysmon provides the parent process context that is the primary differentiator between legitimate administrative time queries and attacker-initiated discovery.
• PowerShell Script Block Logging is enabled via Group Policy, generating Event ID 4104. This captures WMI-based time discovery performed via PowerShell's Get-WmiObject or Get-CimInstance, which does not generate a child process and would otherwise be invisible to process creation monitoring.
• Endpoint agents or Windows Event Forwarding are configured to forward Security and Sysmon logs from all monitored endpoints to Log360. The rule fires on endpoint-level telemetry from workstations and servers, not only from domain controllers.

Note
The System Time Discovery Identified rule is most effective when correlated with other discovery rule alerts. If Log360 is not configured to surface correlated discovery activity clusters (for example, time discovery followed by whoami and net group within 60 seconds on the same host), the rule may generate a high volume of low-confidence alerts. Review the correlation configuration in Log360 before enabling this rule in a high-noise environment, and consider applying host-based or user-based scope filters to reduce false positives during the initial tuning period.

Detecting system time discovery using Log360

Once log collection is configured, follow these steps to enable and tune detection in Log360:

Step 1: Enable the detection rule

Navigate to Security > Manage Rules > Rule Library in the Log360 console. Install and enable the rule: System Time Discovery Identified. Configure an alert profile for the same.

Step 2: Tune the rule for your environment

Exclude known legitimate sources. Once the baseline review is complete, add known-legitimate parent processes, accounts, and host-schedule combinations to a scoped exclusion list. Keep exclusions specific: exclude the process name and parent combination, not the entire host or user account.

Step 3: Read the alert

When the alert fires, the alert will display the hostname, the account that ran the time discovery command, the specific command and arguments, the parent process that spawned it, and the timestamp. The most important fields are the parent process name and the user account. A time query spawned by WINWORD.EXE or a browser process is an immediate escalation trigger. A time query by a standard user account that has never run this command before warrants investigation. A time query by a known admin account from an admin workstation during business hours is almost certainly benign and can be closed after verification.

Investigating an alert

When the System Time Discovery Identified rule fires, an L1 or L2 analyst should work through the following steps:

• Check the parent process immediately. Open the alert detail and identify the process that spawned the time discovery command. If the parent is an office application, a browser, a script interpreter (wscript.exe, mshta.exe, cscript.exe), or any process that has no business running system commands, treat this as a high-priority alert and proceed directly to step 3. If the parent is cmd.exe, PowerShell, or a known administrative tool, continue with the remaining steps before determining priority.
• Check for a discovery command cluster. Query Log360 for all process creation events on the same host in the 120 seconds surrounding the time discovery alert. Look for other discovery commands: whoami, ipconfig, net user, net group, net localgroup, nltest, systeminfo, tasklist, or arp. If three or more discovery commands appear in the same window, the host is under active post-exploitation enumeration. Escalate immediately.
• Assess the user and host context. Determine whether the account that ran the time discovery command has a history of running this command on this host. Check the account's role: a standard business user running w32tm or net time is a stronger anomaly indicator than an IT administrator doing the same. Check whether the host is one that would be expected to run time discovery commands as part of its normal function.
• Check for preceding suspicious activity. Query Log360 for the 30 minutes before the time discovery alert on the same host. Look for unusual logon events (Event ID 4624 Type 3 from an unrecognised source IP), new process creation events for unusual binaries, or file creation events in Temp or AppData directories. If any of these are present, the time discovery is likely part of an ongoing post-exploitation sequence.
• Check for follow-on activity. Query Log360 for the 15 minutes after the alert on the same host. Look for lateral movement indicators: net use, net view, remote PowerShell sessions, or SMB connections to internal hosts not previously seen in the host's connection history. Time discovery is a precursor activity; what follows it is often more indicative of the attacker's intent.
• Verify against known legitimate activity. Check whether the time discovery can be attributed to a known administrative task, a scheduled script, or a software deployment. If the activity is expected and attributable, close the alert with a documented note. If it cannot be attributed, escalate to L2 for deeper investigation regardless of the individual signal confidence.

Escalation trigger
Escalate immediately to L2 or L3 if the time discovery command was spawned by an office application, browser, or script interpreter; if three or more discovery commands fired on the same host within a 120-second window; if the executing account is a standard business user with no prior history of running system commands; or if any unusual logon event or new binary creation preceded the time discovery alert on the same host within 30 minutes.

Responding and remediating

Immediate containment

• If the alert is confirmed as part of an active post-exploitation sequence, isolate the affected host from the network using EDR host isolation or by disabling the network adapter. Do not reboot the host before capturing volatile evidence, as the attacker's tools or implants may be resident only in memory.
• Disable the affected user account if the discovery commands were run under a named user account rather than SYSTEM or a service account. Force a password reset and review all systems the account has authenticated to in the preceding 72 hours.
• If a cluster of discovery commands has been confirmed, treat the host as actively compromised and escalate to incident response. A discovery cluster indicates an attacker is actively characterising the environment, which is a precursor to lateral movement or payload deployment in most intrusion sequences.

Forensic preservation

• Export the Windows Security event log and Sysmon operational log from the affected host covering the full period from the first unusual event to the time of containment. These logs provide the complete discovery sequence and the process context for each command.
• If a suspicious parent process was identified (such as an office application that spawned system commands), extract and hash the originating file. If the file was an email attachment or a downloaded document, preserve it as evidence and submit it to a sandbox for analysis.
• Capture a memory image if the host is believed to be actively compromised, before any reboot or remediation. An attacker's implant that performed the discovery sequence may be loaded only in memory and will be lost on reboot.

Eradication and recovery

• If an implant or malicious script was identified as the source of the discovery commands, remove it and all associated files, scheduled tasks, registry persistence entries, and startup items before returning the host to service.
• If the discovery sequence was attributed to a malicious document opened by a user, review the email gateway logs to determine whether the same document was delivered to other users in the organisation. Run a targeted search for the document's hash across all endpoints.
• Rotate credentials for the affected user account and for any other account whose credentials were accessible on the affected host, regardless of whether credential harvesting was confirmed. A host under active post-exploitation enumeration should be treated as having its credentials exposed.

False positive guidance

System time discovery commands appear frequently in legitimate administrative and operational contexts. The following scenarios are the most common sources of false positive alerts:

• Login scripts and Group Policy: many organisations use login scripts that run net time or w32tm to synchronise clocks against a domain NTP source at user login. These will fire the rule on every login for every user covered by the script. Identify the script by its parent process (typically cmd.exe spawned by userinit.exe or explorer.exe) and the consistent account and host pattern, then exclude the specific process and parent combination.
• Monitoring and management agents: RMM tools, endpoint management agents, and infrastructure monitoring software regularly query system time as part of their health check routines. These will appear as net time or w32tm commands run by the agent's process. Verify the parent process is the documented agent binary and add a scoped exclusion.
• IT administrator activity: helpdesk and systems administrators routinely run time-related commands when troubleshooting NTP synchronisation issues or confirming system settings. These will appear as time commands run from cmd.exe or PowerShell by admin accounts during business hours. Verify the account and context and close if legitimate.
• Automated build and test pipelines: CI/CD pipelines and automated test environments sometimes include time checks as part of their test scripts. These will appear as clustered commands from a build agent process on a known build server. Exclude the build server hostname and the build agent parent process specifically.

Key differentiator
Legitimate system time discovery is predictable and attributable. It runs from a known parent process, at a consistent time, from a consistent account, on hosts where the activity has been observed before. Attacker-initiated time discovery is anomalous on at least one dimension: an unusual parent process, an account that has never run these commands before, a host outside its normal activity pattern, or appearance alongside other discovery commands in rapid succession. If the time discovery alert cannot be attributed to a documented administrative task or known software behaviour, investigate rather than dismiss it.

Hardening and prevention

Because system time discovery uses built-in Windows utilities, prevention at the binary level is not practical for most environments. The following controls reduce the risk and detectability of attacker-initiated time discovery:

• Deploy Sysmon with parent process logging enabled on all endpoints. The parent process context is the single most effective differentiator between legitimate and malicious time discovery commands. Without it, the rule generates significantly more noise and lower-confidence alerts.
• Enable PowerShell Script Block Logging on all endpoints to capture WMI-based and API-based time discovery that does not generate command-line process creation events. Without Script Block Logging, techniques that avoid spawning net.exe or w32tm.exe are invisible to process creation monitoring.
• Apply application control policies that prevent office applications, browsers, and script interpreters from spawning system command binaries. If WINWORD.EXE cannot spawn cmd.exe or PowerShell, the most dangerous class of time discovery (malicious document delivery) is blocked at the execution layer before it reaches log-based detection.
• Configure NTP synchronisation via Group Policy so that endpoints synchronise automatically using the Windows Time Service without requiring manual net time commands. This reduces the legitimate use of time discovery commands in the environment and makes anomalous occurrences easier to identify.
• Build correlated discovery cluster alerting in Log360. The System Time Discovery rule in isolation is a low-to-medium confidence signal. Its value multiplies significantly when correlated with other discovery commands on the same host. Invest in the correlation configuration before the rule goes live.