System Time Discovery (T1124) is a discovery technique. MITRE lists ESXi, Linux, macOS, network devices and Windows.
Reading the time is about as ordinary as an operation gets. The technique matters only because of what it enables, and that is where defenders should look.
How attackers use it
MITRE describes gathering the system time or time zone settings from a local or remote system. Time is set and stored by services such as the Windows Time Service on Windows, or systemsetup on macOS, and may be synchronized across an enterprise by a network time server.
Ways to get it, per MITRE:
- On Windows,
net time \\hostnamereturns the time of a remote system.w32tm /tzcan reveal the time zone. Functions such as GetTickCount() show uptime. - On network devices, CLI commands such as
show clock detailshow time configuration. - On ESXi,
esxcli system clock getdoes the same. - On Linux, system calls such as time() collect the current time.
- On macOS,
systemsetup -gettimezoneor timeIntervalSinceNow give the time zone or the current date and time.
MITRE notes the information can support other techniques, such as running a file as a scheduled task or job, or working out locality from the time zone to help target a victim.
How to detect it
MITRE's strategy is a behavior chain, platform aware. Its analytics describe:
- Windows: an untrusted or unusual process or script such as cmd.exe, powershell.exe, w32tm.exe or net.exe querying time or time zone, optionally followed shortly by time-based scheduling or conditional execution, such as schtasks /create, at.exe or a long sleep.
- Linux: a process run by a shell, interpreter or implant using date, timedatectl, hwclock, /etc/timezone or /proc/uptime, optionally followed by cron or at changes or conditional sleep logic.
- macOS: systemsetup -gettimezone, date or ioreg, followed by launchd plist changes or sleep-based execution.
- ESXi: esxcli system clock get or similar queries, soon followed by NTP configuration checks or scheduled task creation, by non-standard accounts or outside maintenance windows.
- Network devices: rare users or locations running show clock or show timezone, then changing time or NTP settings. AAA or TACACS+ accounting and syslog tie the command to identity, source address and privilege level.
The rule is simple. Ignore the time check by itself. Alert when it is chained with scheduling or conditional execution, or when it comes from an account or place that never does it.
How to reduce the risk
MITRE lists no formal mitigation, because time is a normal OS function. Useful steps:
- Collect process command lines on all platforms, including ESXi and network device accounting.
- Review scheduled task and cron creation, which is where time discovery often leads.
- Keep NTP settings under change control.
Check your own environment
- Do you log command lines for w32tm, net time, date and similar tools?
- Do you alert on new scheduled tasks, cron jobs and launchd entries?
- Do network devices and ESXi hosts send command accounting to a central log?
- Are time sources protected from unapproved changes?
# Windows (cmd): check that command line auditing for process creation is configured (read-only)
auditpol /get /subcategory:"Process Creation"
Quick check
What does MITRE say time information may be used for?
Timing scheduled tasks or jobs, and inferring locality from the time zone to help target a victim.
What turns a time check into a useful alert?
Following it with scheduling or conditional execution, or seeing it from a rare account, location or outside a maintenance window.
Sources
- MITRE ATT&CK, System Time Discovery (T1124)
