MITRE ATT&CK T1029 Scheduled Transfer: Detecting Timed and Recurring Exfiltration

Scheduled Transfer (T1029) is exfiltration that keeps office hours: malware sends stolen data only at set times or fixed intervals so that it blends into the traffic your network already expects. ATT&CK v20 lists T1029 under Exfiltration (TA0010) for Windows, Linux and macOS, and notes that it almost always rides on another exfiltration technique such as Exfiltration Over C2 Channel (T1041) or Exfiltration Over Alternative Protocol (T1048). The timing is the evasion. That makes it a detection problem about regularity: which processes, jobs and accounts talk to the same destination on a clock, and which of those you can explain. This page covers how malware families implement scheduled transfer, the v20 detection strategy, beacon and periodicity analysis, the scheduled jobs and service accounts that carry legitimate transfers, and how to test. It is written for detection engineers and network security teams. For the wider exfiltration picture, see the Data Exfiltration Guide; this page does not repeat it.

Key takeaways

• Two flavours of timing. ATT&CK v20 procedure examples show fixed intervals (ADVSTORESHELL and Machete every 10 minutes, ShadowPad every 8 hours) and business-hours windows (ComRAT sleeping outside 9 to 5, Monday to Friday; Dipsind running only in working hours).
• Regularity is the signal. v20 detection strategy DET0399 looks for recurring transfers by scheduled or script-based processes with time-based regularity and consistent external destinations.
• Schedulers are part of the evidence. v20 names Windows Task Scheduler events 106 and 200, cron activity and launchd plists as log sources, so link the job to the connection, not just the connection to the host.
• Business-hours malware defeats night-time rules. Alerting on "traffic at 3am" misses implants built to send only during the working day.
• Legitimate scheduled transfers run as service accounts. Backups, SFTP feeds and sync jobs are the cover; an inventory of approved jobs, their identities and destinations is what makes the anomalies visible.

What T1029 is in ATT&CK v20

ATT&CK describes Scheduled Transfer as adversaries scheduling exfiltration to run only at certain times of day or at certain intervals, to blend with normal traffic patterns or to match availability. Version 1.2 of the technique (last modified 3 September 2026) has no sub-techniques and lists one mitigation, Network Intrusion Prevention (M1031).

T1029 describes when data leaves, not how. Pair it with the channel technique to understand the full behaviour:

• Over the C2 channel (T1041): the implant's own beacon carries the data on its normal check-in schedule.
• Over an alternative protocol (T1048): a scheduled job pushes files over FTP, SFTP, DNS or another protocol. See the T1048 Exfiltration Over Alternative Protocol page.
• Over a web service (T1567): a timed sync to cloud storage. See T1567 Exfiltration Over Web Service.
• Automated (T1020): collection and transfer without operator action, which often uses a schedule. See MITRE ATT&CK T1020 Automated Exfiltration.

The schedule itself is usually implemented in one of two places: inside the implant (a sleep timer or working-hours check in its configuration), or in the operating system scheduler (a scheduled task, cron entry or launchd job that runs a transfer script). The second creates persistence artefacts covered by Scheduled Task/Job (T1053). See the T1053 Scheduled Task/Job Defensive Guide.

How adversaries use it: recorded cases

ATT&CK v20 lists 18 groups and software families with T1029 procedure examples. A selection by timing pattern:

Two lessons follow. Fixed-interval families are easy to find with periodicity analysis once you look. Working-hours and jittered families are built to defeat the two most common shortcuts, out-of-hours alerting and exact-interval matching, so detection has to tolerate variance and weigh destination and process context. See the Turla Threat Actor Profile for the group behind ComRAT and TinyTurla, and the Cobalt Strike Abuse Detection Guide for jittered beacons.

What to detect and where

ATT&CK v20 detection strategy DET0399 (Scheduled Transfer and Recurrent Exfiltration Patterns) has one analytic per platform.

Sysmon network connection logging (event 3) is disabled by default and is enabled through the NetworkConnect filter in the Sysmon configuration; without it, the Windows analytic has no process-to-connection link.

Tunable elements

Periodicity analysis on network data

Network flow and proxy data can find scheduled transfers even when the endpoint is unmanaged. The method, as an NHI Mgmt Group recommendation:

• Group connections by source host, destination and, where available, process or user agent.
• Measure interval regularity: the spread of time between connections (low spread means a timer) and the spread of bytes sent (similar sizes suggest automated uploads).
• Score over long windows: a 10 minute beacon shows within hours, an 8 hour schedule needs days of data. Keep at least 7 days for periodicity scoring.
• Weight by destination rarity: a regular connection to a destination no other host uses is far more interesting than one to a popular SaaS service.
• Use open tooling where it fits: the open source RITA project scores beaconing, long connections and DNS tunnelling from Zeek logs, and supports filtering by beacon score.

See the Beaconing and C2 Detection Guide for scoring detail and the NetFlow and IPFIX Flow Telemetry Guide for collection.

High-value signals

• A newly registered scheduled task, cron entry or LaunchAgent whose action runs an archiver, script interpreter or transfer tool, followed by outbound connections on its schedule.
• Regular outbound connections from a process that is not a known updater, agent or sync client, to a destination no other host uses.
• Transfers that stop at weekends and resume on Monday from a host that is not a user workstation.
• A legitimate scheduled transfer job whose destination, size or service account changes without a change record.

Where identity fits: the accounts behind scheduled jobs

Most legitimate scheduled transfers run under service accounts: backup agents, SFTP feeds to partners, reporting exports and cloud sync jobs. They are exactly the cover an adversary wants, and they often hold credentials for the destination in the job definition or script.

• Inventory approved transfer jobs with their owner, service account, schedule, destination and expected volume. This becomes the DestIPAllowlist and ParentProcessBaseline.
• Bind service accounts to their job: alert when a transfer service account runs from a new host, at a new time or to a new destination.
• Remove credentials from job definitions: passwords and keys in cron lines, task arguments and scripts let an intruder reuse the job's identity. See How to Find credentials in cron jobs and scheduled tasks.
• Watch for new tasks created by service accounts: a service account registering a scheduled task is rarely normal.

Mitigations

How to roll out and test

1. Build the approved job inventory on servers first, then on workstations, and record the service account and destination for each.
2. Enable telemetry: Sysmon network connections, Task Scheduler operational logging, cron logging and macOS Endpoint Security or equivalent EDR events, plus flow or proxy logs at egress.
3. Start with new-job alerts: scheduled tasks, cron entries and LaunchAgents that run transfer tools are low noise and fast to build.
4. Add periodicity scoring in report-only mode for two to four weeks, tuning destination allow-lists and known agents.
5. Emulate safely: in an approved test ring, create a benign scheduled job that uploads a canary file to a controlled external server every 10 minutes, and a second one that runs only in working hours with random jitter. Use an authorised emulation framework mapped to T1029. Confirm both are found.
6. Promote and maintain: move rules to alerting, and require a change record to add any destination to the allow-list. Roll back to report-only if a new backup or sync product floods the rule.

Metrics

• Coverage of approved transfer jobs: percentage with an owner, service account and destination recorded.
• Unexplained periodic connections: count per week after tuning, each triaged.
• Detection of emulated schedules: fixed-interval and working-hours tests detected, with time to alert.
• Servers with default-deny egress: percentage of the estate.

Common failure patterns

• Out-of-hours rules only: implants such as ComRAT and Dipsind are built to transfer during the working day.
• Exact-interval matching: jittered beacons vary their timing, so rules need tolerance and destination context rather than a fixed period.
• Short retention: an 8 hour schedule cannot be scored on 24 hours of data.
• Allow-listing by destination alone: an attacker who reuses an approved SaaS or SFTP destination passes; bind allow-lists to the job, account and host.
• Sysmon without network events: event 3 is off by default, so the process-to-connection link the Windows analytic needs is missing.

Framework mapping

Practitioner checklist

• Inventory approved scheduled transfer jobs with owner, service account, schedule and destination.
• Enable Sysmon event 3, Task Scheduler logging, cron logging and launchd monitoring.
• Alert on new scheduled tasks, cron entries and LaunchAgents that run transfer tools or archivers.
• Score periodic outbound connections over at least 7 days, weighted by destination rarity.
• Do not rely on out-of-hours rules; test against working-hours and jittered schedules.
• Apply default-deny egress to servers and bind allow-lists to job, account and host.
• Remove credentials from task definitions and scripts and alert on service accounts creating tasks.

Standards and references

• MITRE ATT&CK: T1029 Scheduled Transfer
• MITRE ATT&CK: S0126 ComRAT
• MITRE ATT&CK: M1031 Network Intrusion Prevention
• Microsoft Learn: Sysmon
• Active Countermeasures: RITA project documentation
• NIST: SP 800-53 Rev 5 Security and Privacy Controls

Related NHI Mgmt Group resources: ATT&CK Exfiltration Tactic · Data Exfiltration Guide · Beaconing and C2 Detection Guide · NDR Guide