AN1119: Analytic 1119
Detection of cron-based or script-based recurring transfers where the same script, user, or destination reappears at predictable intervals.
Analyst context for executives and security teams
This analytic matters because recurring, predictable transfers from Linux systems can represent scheduled business automation or suspicious automated movement of data. For leaders, the key decision is not simply whether cron or scripts exist, but whether the organization can distinguish approved recurring transfers from unapproved ones before they become an incident or audit issue.
Executive priority
Prioritize validation where Linux systems handle sensitive data, regulated records, operational files, or business-critical automation. Security leaders should ask whether SOC and incident response teams have enough evidence to identify the script, user, destination, and schedule behind recurring transfers, and whether exceptions for approved jobs are documented. This supports operational resilience, compliance evidence, and faster incident scoping when repeated outbound activity is questioned.
Technical view
AN1119 is a Linux-focused detection analytic for cron-based or script-based recurring transfers where the same script, user, or destination appears at predictable intervals. Because ATT&CK provides no separate detection logic for this analytic, teams should validate whether their telemetry can correlate process execution, scheduled job context, user identity, transfer destination, and timing patterns. The most useful investigation path is to baseline known recurring jobs, then review repeated transfer behavior that reuses the same account, script path, command pattern, or external/internal destination on a regular cadence.
Likely telemetry
- Linux cron and scheduled task records
- Process execution telemetry for scripts and transfer utilities
- User/account context associated with scheduled jobs
- Network connection or flow records showing repeated destinations
- Command-line and script path evidence where collected
Detection direction
- Confirm that Linux scheduled execution activity is logged with enough detail to identify job owner, script path, command line, and timing.
- Build or tune detections around repeated transfers with predictable intervals involving the same user, script, or destination.
- Maintain allowlists or documented baselines for approved business automation to reduce false positives.
- Review blind spots where cron logs, process command lines, or network destination data are not centrally collected.
- Correlate timing patterns with destination recurrence rather than relying on a single transfer event.
Mitigation priorities
- Inventory legitimate cron-based and script-based transfer jobs on Linux systems that handle important data.
- Document expected users, scripts, destinations, schedules, and business owners for approved recurring transfers.
- Restrict scheduled job ownership and script modification rights to authorized accounts.
- Ensure central logging covers cron activity, process execution, user context, and network destinations for relevant Linux hosts.
- Use incident response review to investigate undocumented recurring transfers before applying broad blocking actions that could disrupt business automation.
Analyst notes and limits
The object is a detection analytic, not a technique, and no tactics or relationship context were supplied. The practical value comes from validating whether recurring Linux transfer behavior can be separated from normal automation using local baselines and telemetry.
The official object provides a short description only and no formal detection logic, related ATT&CK techniques, procedures, mitigations, or data source mappings. Environment-specific context is required to decide what transfer activity is normal, suspicious, or business critical.
Analytic 1119
Detection of cron-based or script-based recurring transfers where the same script, user, or destination reappears at predictable intervals.
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 | c9fa3cd92749… |
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 AN1119Open 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.