AN0431: Analytic 0431
A process (often spawned by a shell, interpreter, or malware implant) executes time discovery via commands (date, timedatectl, hwclock, cat /etc/timezone, /proc/uptime) or direct syscalls (time(), clock_gettime) and is (optionally) followed by scheduled task creation/modification (crontab, at) or conditional sleep logic.
Analyst context for executives and security teams
AN0431 highlights Linux processes checking system time or uptime, sometimes before creating scheduled tasks or entering conditional sleep logic. For leaders, the value is not that time checks are rare—they are common—but that suspicious time discovery can be an early clue that an implant, script, or unauthorized automation is preparing delayed execution, scheduling, or environment-aware behavior.
Executive priority
Treat this as a SOC validation and resilience question: do Linux security logs show which users and processes query time sources, read uptime/timezone files, and modify cron or at jobs? Coverage matters for incident scoping, audit evidence around privileged automation, and confidence that delayed or scheduled activity will not be missed during response. Priority should be higher on Linux servers supporting critical operations, identity infrastructure, cloud workloads, or regulated systems where unauthorized scheduling could affect availability or investigation timelines.
Technical view
This analytic is Linux-focused and describes processes executing time discovery through commands such as date, timedatectl, hwclock, cat /etc/timezone, or /proc/uptime, or through direct syscalls such as time() and clock_gettime(). SOC and detection teams should validate visibility into process lineage, especially shells, interpreters, and unusual binaries, then correlate time discovery with subsequent crontab or at activity, file reads of time-related paths, or long sleep/conditional execution behavior. Because official detection logic is not provided, local baselining is required to separate normal administration, monitoring, backup, and application runtime behavior from suspicious chains.
Likely telemetry
- Linux process creation events with command line, user, parent process, working directory, and executable path
- Shell and interpreter execution telemetry for bash, sh, Python, Perl, PHP, or similar runtimes where collected
- File access or command telemetry involving /etc/timezone and /proc/uptime
- Audit or endpoint telemetry for timedatectl, hwclock, date, crontab, and at execution
- Cron and at job creation or modification records, including user context and job contents where available
Detection direction
- Start with correlation rather than single-event alerting: time discovery alone is common and likely noisy.
- Prioritize process chains where time discovery is launched by unexpected shells, interpreters, temporary-directory executables, service accounts, or unknown binaries.
- Correlate time discovery with nearby crontab or at changes, new scheduled commands, or suspicious long-running sleep behavior.
- Baseline legitimate sources of repeated time checks, including monitoring agents, backup tools, configuration management, container runtimes, and application health checks.
- Validate that Linux endpoint telemetry preserves parent-child process relationships and full command lines; without those fields, this analytic loses much of its decision value.
Mitigation priorities
- Do not attempt to block routine time queries broadly; they are normal operating system and application behavior.
- Harden and monitor scheduled task mechanisms such as cron and at, especially for privileged users and service accounts.
- Limit who can create or modify scheduled tasks and review permissions on production Linux systems.
- Ensure centralized logging captures process execution and scheduled task changes from critical Linux assets.
- Maintain baselines for approved automation so SOC teams can identify unusual scheduling or time-checking patterns during investigations.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic, not a technique, and it has no tactic mapping or relationship context. The practical value is strongest when combined with local process lineage, user context, and scheduled-task telemetry. Glexia would use this as a coverage-validation item for Linux monitoring and incident response rather than as a standalone high-confidence alert.
Official detection content was not provided, and no related techniques, groups, software, mitigations, or data components were supplied. Conclusions are limited to the official description, Linux platform field, and external reference. Local environment baselines are required before operationalizing alert thresholds.
Analytic 0431
A process (often spawned by a shell, interpreter, or malware implant) executes time discovery via commands (date, timedatectl, hwclock, cat /etc/timezone, /proc/uptime) or direct syscalls (time(), clock_gettime) and is (optionally) followed by scheduled task creation/modification (crontab, at) or conditional sleep logic.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 4fee97b7a234… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN0431Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.