Live Active security incident? Get immediate response
MITRE ATT&CK® Analytic

AN1049: Analytic 1049

Shell scripts or binaries invoking repeated 'sleep', 'ping', or low-level syscalls (e.g., nanosleep) in short-lived execution chains with no user or system interaction. Frequently seen in malicious cron jobs or payload stagers.

EnterpriseAN1049AnalyticObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

This analytic matters because repeated delay behavior in Linux shell scripts or binaries can indicate automation designed to wait, evade timing-based review, or stage later activity without user interaction. For leaders, the value is not in treating every use of sleep or ping as suspicious, but in confirming whether SOC and incident response teams can distinguish normal scheduled administration from short-lived, unattended execution chains such as cron-driven jobs or payload stagers.

Executive priority

Prioritize this as a Linux monitoring and response-readiness question: do teams have enough process, script, and scheduling telemetry to investigate suspicious unattended execution? It supports decisions around managed detection scope, Linux endpoint visibility, audit evidence for monitoring coverage, and incident triage speed. Because ATT&CK supplies no tactic mapping, relationships, or official detection logic here, it should be used as a validation prompt rather than a standalone risk conclusion.

Technical view

For Linux environments, validate visibility into shell scripts and binaries that repeatedly invoke delay mechanisms such as sleep, ping used as a timing surrogate, or low-level sleep-related syscalls like nanosleep. Focus analysis on short-lived process chains with no clear user or system interaction, especially when launched from cron or other scheduled contexts. Since no official detection is provided, detection engineering should build local baselines for legitimate automation and tune around parent process, command-line pattern, execution frequency, script path, user context, and absence of interactive session indicators.

Likely telemetry

  • Linux process creation events with command line and parent/child process context
  • Script execution telemetry for shell interpreters and binaries
  • Cron or scheduled job configuration and execution logs
  • User/session context showing whether execution was interactive or unattended
  • Endpoint telemetry capable of observing repeated sleep, ping, or nanosleep-like delay behavior

Detection direction

  • Do not alert on sleep or ping alone; validate repeated delay calls within short-lived, unattended execution chains.
  • Tune against known-good administrative scripts, monitoring checks, backup jobs, and scheduled maintenance tasks that legitimately use delays.
  • Correlate process behavior with cron or scheduled execution context when available, because the official description highlights malicious cron jobs as a common setting.
  • Use parent process, user account, working directory, script location, and execution cadence to reduce false positives.
  • Treat lack of official detection logic and lack of relationship context as a reason to test detections in local Linux environments before operationalizing.

Mitigation priorities

  • Inventory and review Linux scheduled jobs and automation paths that can launch shell scripts or binaries.
  • Ensure endpoint and log collection captures process command lines, parent process context, and cron execution evidence where appropriate.
  • Apply least-privilege and change-control practices to accounts and locations that create or modify scheduled jobs and scripts.
  • Establish baselines for legitimate unattended Linux automation so SOC teams can investigate unusual delay-heavy chains quickly.
  • Prepare incident response playbooks for suspicious scheduled execution, including containment, script preservation, and timeline reconstruction.
Analyst notes and limits

This object is a detection analytic, not a technique. It is limited to Linux and describes repeated delay behavior in shell scripts or binaries, with examples including sleep, ping, and nanosleep. The supplied object has no tactics, no official detection text, and no relationship context, so the take emphasizes telemetry validation and local baselining rather than a definitive detection rule.

Assessment is constrained to the supplied ATT&CK fields and external reference. No active exploitation, attribution, affected products, impact, or guaranteed detection coverage can be inferred. Local environment evidence is required to determine whether observed delay behavior is benign automation or suspicious unattended execution.

Official MITRE ATT&CK definition

Analytic 1049

Shell scripts or binaries invoking repeated 'sleep', 'ping', or low-level syscalls (e.g., nanosleep) in short-lived execution chains with no user or system interaction. Frequently seen in malicious cron jobs or payload stagers.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

Change history

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 .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
1fdac7a62ef27234...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 1fdac7a62ef2…
Raw source

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.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack AN1049
    Open source URL
Source and licensing

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.