AN1114: Analytic 1114
Background scripts (e.g., via cron) or daemons transmitting data repeatedly to remote IPs or URLs.
Analyst context for executives and security teams
This analytic matters because repeated outbound connections from Linux background jobs can indicate automated data movement or unauthorized persistence-driven communications. For leaders, the value is not the label “cron or daemon traffic,” but whether the organization can prove it can see scheduled or service-based Linux processes making repeated remote connections before they become an incident response blind spot.
Executive priority
Prioritize this as a Linux monitoring and egress-visibility validation item. It supports operational resilience and audit readiness by testing whether SOC and IR teams can connect three facts: a background execution source, repeated outbound destinations, and the business legitimacy of that traffic. The supplied ATT&CK object does not specify tactics or detection logic, so it should be treated as a coverage gap-check rather than a complete detection package.
Technical view
For Linux environments, validate whether telemetry can identify cron-launched scripts and daemon/service processes that repeatedly transmit data to remote IPs or URLs. Because no official detection logic or relationships are provided, teams should build local baselines for expected scheduled-job and daemon network behavior, then review deviations such as unusual destination patterns, repeated connections, or processes whose network activity does not match their operational purpose.
Likely telemetry
- Linux process execution records showing parent/child process context for scheduled jobs and daemons
- Cron configuration and job execution logs where available
- Linux service or daemon activity logs
- Network connection telemetry from Linux hosts, including destination IPs, URLs, ports, and connection frequency
- DNS or proxy logs that can associate repeated remote destinations with Linux hosts
Detection direction
- Confirm that Linux endpoint and network telemetry can tie outbound connections back to the responsible process or service, not only the host.
- Baseline approved cron jobs, scripts, and daemons that legitimately communicate externally to reduce false positives.
- Tune for repeated outbound transmission patterns to remote IPs or URLs from background execution contexts, while accounting for normal software update, monitoring, backup, and management agents.
- Review blind spots where minimal Linux logging, containerized workloads, NAT, or proxy aggregation may hide the originating process or workload.
- Because ATT&CK provides no official detection text for this analytic, document local detection assumptions, data dependencies, and test results.
Mitigation priorities
- Inventory Linux scheduled jobs, scripts, services, and daemons that are authorized to communicate externally.
- Restrict unnecessary outbound connectivity from Linux servers and workloads using network egress controls appropriate to the environment.
- Apply least privilege to service accounts and execution contexts used by background jobs.
- Maintain change control for cron entries, service definitions, and background scripts so new recurring network activity is reviewable.
- Ensure IR playbooks include triage steps for mapping repeated outbound traffic to a Linux process, owner, destination, and business justification.
Analyst notes and limits
This is a detection analytic object, not a technique description. The supplied description is narrow: background scripts such as cron jobs or daemons repeatedly transmitting data to remote IPs or URLs on Linux. No ATT&CK tactics, related techniques, procedure examples, or official detection pseudocode were supplied, so defensive guidance should be validated against local Linux architecture and normal administrative tooling.
The object has no official detection content and no relationship context. It does not specify attacker intent, data type, impact, attribution, or active exploitation. Any prioritization beyond Linux background-process network visibility requires local asset criticality, egress policy, and telemetry evidence.
Analytic 1114
Background scripts (e.g., via cron) or daemons transmitting data repeatedly to remote IPs or URLs.
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 | cce6701aa28e… |
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 AN1114Open 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.