How T1029 scheduled transfer hides exfiltration in regular traffic
T1029 Scheduled transfer is an Exfiltration technique in MITRE ATT&CK Enterprise, listed under tactic TA0010, in which the adversary moves data out of the environment on a timetable it controls. ATT&CK frames the tactic simply: "The adversary is trying to steal data." For a SOC lead, the difficulty is that a recurring outbound job looks like routine work, such as a nightly backup, a file sync or a monitoring agent that already runs at fixed intervals. Fixed timing, stable destinations and predictable volume give the transfer the same shape as approved traffic, so detections that only look for large or unfamiliar flows can miss it.
In intrusions, this technique typically appears after collection has gathered the data the adversary wants, when the remaining step is getting that data out without drawing attention. The scheduled element may live in a job the adversary created or in an existing scheduler the adversary has changed, so the recurring outbound pattern is often the first thing defenders can see. Decisions to make now include which recurring outbound flows are approved, who owns each scheduled job on Linux, macOS and Windows hosts, and whether any job sends data to a destination outside its documented purpose. As an illustrative check, compare a nightly transfer's destination and time window against the change record for the job that should own it.
Mappings are version specific. This page references Enterprise ATT&CK version 20.0, and detection content should name that version so the team can see when a technique is renamed, deprecated or revoked in a later release. Before relying on any mapping, confirm the technique ID, its sub-techniques and the data components in the version your tooling targets, using the STIX bundles published in the attack-stix-data repository. The MITRE ATT&CK updates page lists what changed in each release.
Which telemetry reveals scheduled transfers on Linux, macOS and Windows
This table maps the data components ATT&CK links to T1029 Scheduled transfer onto the signal to look for, the platform where it appears and an open-source collector that can gather it. Read each row as a starting point for a detection, then confirm the data component mapping against the ATT&CK v20.0 bundle for this technique before you build rules. The main takeaway is that connection timing and process context together are what make a scheduled transfer stand out from normal traffic.
| Data component | Signal to look for | Platform and collector |
|---|---|---|
| Network Connection Creation (DC0082) | Outbound connections from the same process at a regular interval, to a destination not seen in the baseline | Linux, macOS and Windows: Wazuh agent or Velociraptor artifacts that record socket creation |
| Process Creation (DC0032) | Unexpected binaries or scheduler jobs that start network-capable tools on a timer | Linux and macOS: Wazuh agent process events. Windows: Sysmon or Wazuh event logs for process creation |
| Network Traffic Flow (DC0078) | Repeated flows with similar byte counts and intervals, visible even when payload is encrypted | All platforms at the network edge: Zeek connection logs or Suricata flow records |
| Scheduled Job Creation (related to scheduled execution) | New cron entries, systemd timers, launchd agents or Windows scheduled tasks that invoke transfer tools | Linux and macOS: Wazuh file integrity monitoring on cron and launchd paths. Windows: Wazuh event logs for task creation |
| Network Traffic Content (DC0085) | Payload metadata or protocol anomalies on cleartext or inspectable sessions | Zeek or Suricata with content inspection where traffic is visible; confirm TLS inspection scope with your team |
| File Access (DC0055) | Staged archives or data sets read on a schedule just before outbound sessions | Linux, macOS and Windows: Wazuh file monitoring or Velociraptor file collection on defined staging paths |
Detection ideas for recurring outbound transfers
T1029 Scheduled transfer hides in traffic that looks routine: a job sends data on a timer, so the signal is regularity, destination and origin rather than a single large event. The cards below pair each timing or volume pattern with the process and flow context needed to separate an adversary's job from the backups, patch cycles and agents that run on the same schedule.
Recurring volume to one destination
Build a baseline of outbound bytes per host and destination pair, then alert when the same destination receives transfers at a steady interval with volume above that host's normal range. The logic looks for periodicity, not size alone, so a nightly upload that repeats within a narrow time window stands out even when each transfer is small. Tune the interval tolerance and the baseline window to each segment, since batch systems and file sync tools produce regular patterns by design. Check whether the destination is internal, a known backup target or a cloud storage endpoint already approved for that workload.
New destinations on a schedule
Flag destinations that a host has never contacted before and that appear at the same time of day across several days. A rare domain or IP reached only during a fixed window is more telling than a rare destination reached at random. Set the first-seen window and the minimum number of repeat days to match your change cycle, because new vendor endpoints added during maintenance will trigger this logic. Review the resolving process, the certificate issuer and whether the destination appears in your asset inventory.
Process-to-network correlation for jobs
Correlate network connections with the process that opened them and with the scheduled job that launched that process. Alert when an outbound connection originates from a scheduler-launched binary, script interpreter or unusual parent that has not previously made external connections. Sysmon-style process creation and network connection events, or the equivalent in your endpoint agent, make this join possible. Expect false positives from configuration management, package managers and monitoring agents, so maintain an allowlist keyed on signed binary, parent and destination rather than on process name alone.
Zeek and Suricata flow analytics
Use Zeek connection logs to compute inter-arrival times and byte totals per source, destination and service, then feed the summaries into your SIEM for periodicity scoring. Suricata rules can flag specific outbound patterns, but flow-level regularity analysis is usually better suited to Zeek. Test the analytics against captured traffic from your own environment before tuning, and document the sampling and retention settings, since both change what the timing analysis can see. Confirm that your sensors capture both directions of traffic at the egress point.
Backup, patch and telemetry exclusions
Document the recurring transfers your organization expects, including backup windows, patch downloads, endpoint telemetry uploads and certificate or time synchronization traffic. Record each one with its source, destination, schedule and owner, then suppress only those exact combinations. Review the list after every change window, because an exclusion that is too broad will hide a scheduled transfer that reuses an approved destination. Ask backup and patch vendors which endpoints and ports their agents use so the allowlist reflects their documented behavior.
How to confirm a scheduled transfer detection fires
This sequence turns the T1029 Scheduled transfer detection into a measured result: a planned, approved emulation of a benign scheduled transfer in an isolated range, with expected records per platform, clear pass or fail criteria, and a complete record of what fired, when, and under which rule version. It gives the team evidence that the detection works and a baseline for tuning.
Obtain written approval and define scope
Before any activity, the security lead, the range owner and the system owners agree in writing on the emulation's objective, the isolated range it runs in, the named participants, the platforms in scope (Linux, macOS and Windows), and the stop conditions. The emulation must never touch production hosts, production data or shared networks. Done means a signed scope record exists and every participant has confirmed they understand the stop conditions. DeployOpen can help draft this as part of a fixed-scope engagement, but the client's own authority must approve it.
Define the benign synthetic transfer
The red or purple team defines a harmless scheduled transfer of synthetic data, such as generated test files with no sensitive content, moved to a range-controlled destination at a defined schedule. The plan records the source host, the destination, the schedule type and the expected volume, all of which exist only inside the range. Done means the plan describes the behavior in words, names the ATT&CK version it targets, and has been reviewed by a second person who confirms that no real data or real external destinations are involved.
Document expected telemetry per platform
Before the run, the detection engineer writes down which records should appear on each platform: process creation events for the scheduling and transfer activity, network connection creation records for the outbound session, and network traffic flow records from the sensor. The expectations are written separately for Linux, macOS and Windows, because log sources and field names differ. Done means each expected record type has a named source, such as the Wazuh agent, Zeek or Suricata, and a reviewer has signed off on the list.
Set pass and fail criteria
The team agrees on objective criteria before running the emulation. A pass means the expected records were collected in the SIEM, the relevant rule or analytic produced an alert within the agreed review window, the alert carried the expected host and process context, and the alert reached the responder queue. A fail means any of these steps is missing. Partial results are recorded as partial, with the missing link named. Done means the criteria are written, timed, and visible to every participant before execution begins.
Execute the approved emulation in the range
The operator runs the approved benign transfer inside the isolated range, following the written plan and nothing beyond it. An observer records the start and end times of each activity. If any stop condition is met, the operator halts the activity and the observer logs the reason. Done means the operator and observer have both signed the execution log, and the range confirms that no traffic left the isolated segment.
Verify records, alerts and timestamps
The detection engineer compares collected records with the expected list, checking that timestamps across hosts and sensors line up closely enough to reconstruct the sequence. The analyst checks that the alert fired, that it names the correct host and process context, and that it reached the queue. Clock skew, missing fields or dropped sensor records are logged as findings. Done means every criterion has a recorded result of pass, fail or partial, with evidence attached.
Record results and tuning decisions
The team writes a result record for the run containing timestamps, alert IDs, the rule or analytic name and version, the ATT&CK version targeted, any tuning changes made, and the reasoning behind each change. Tuning changes are reviewed and retested in the range before they reach production. Done means the record is stored with the detection's change history, and a follow-up retest is scheduled so the fix is confirmed rather than assumed.
Close the exercise and retain evidence
The team closes the exercise by confirming that all synthetic data and range artifacts are removed or archived according to the plan, that access granted for the exercise is revoked, and that the written approval and result record are retained for audit readiness. Open findings are assigned owners. Done means the range owner has confirmed cleanup in writing and the evidence package is filed where compliance reviewers can find it.
What the schedule itself reveals in network and host data
The core detection idea for T1029 Scheduled transfer is that the timing of a transfer is itself evidence. A scheduled job that sends data out at fixed intervals leaves a pattern in flow records: outbound connections from the same host to the same destination address and port recur at near-constant intervals, carry similar byte counts each time, and often reuse the same destination hostname or certificate. In Network Traffic Flow data (DC0078) and Network Connection Creation events (DC0082), this shows up as a repeating series of short-lived sessions rather than a single long session. Analysts should ask whether the interval, the byte volume and the destination set are stable enough to be a machine schedule, and whether a human or application workload would ever produce the same shape.
Host logs show the other half of the pattern. A transfer that runs on a timer usually has a parent process, a scheduler such as cron, systemd timers, launchd or the Windows Task Scheduler, and a recurring process creation event (DC0032) that matches the same interval as the network sessions. Correlating the two is what turns a noisy outbound connection into a finding. The baseline matters because normal scheduled work also repeats: backups, certificate renewals, telemetry, patch checks and time synchronization all produce periodic outbound traffic. Build baselines per host and per service account, not across the whole estate, so that a backup server's nightly pattern does not hide a workstation that suddenly begins beaconing to an unfamiliar destination. Confirm with your platform and endpoint owners which scheduled jobs are approved, where they are defined and which destinations they are expected to reach, and record that inventory as the reference for alert tuning.
Preventive controls that limit scheduled transfers
Scheduled transfers are routine by design, so preventive controls focus on constraining where scheduled data movement can go and what it can carry. The cards below cover the ATT&CK mitigations most often mapped to Exfiltration techniques, and each one depends on facts about your own environment that you should confirm before relying on it.
Network intrusion prevention
Network Intrusion Prevention (M1031) inspects traffic inline and can block flows that match known-bad or policy-violating patterns. For T1029, the useful question is whether it sees scheduled transfers that run on a fixed cadence to unusual destinations, not only signature hits. Confirm that the sensor sits on the egress path, that TLS traffic from scheduled jobs is visible to it or deliberately excluded, and that blocking mode is enabled for the rules you tested rather than alert-only.
Egress filtering by destination
Filter Network Traffic (M1037) limits which hosts and services can make outbound connections at all. Scheduled jobs usually need a short, known list of endpoints such as backup targets, package mirrors or partner APIs, so an allowlist for those jobs is one of the stronger preventive options. Confirm which servers run scheduled tasks, which destinations each one needs, and who approves a change to that list. Default-deny egress for service accounts is often harder to operate than it looks, so test it in a range first.
Data loss prevention on scheduled outputs
Data Loss Prevention (M1057) watches content and classification labels on data leaving the environment, which matters when a scheduled job packages sensitive records into a file or message. Its value depends on how well your data classification is maintained and whether scheduled exports pass through monitored channels. Confirm which report, sync and export jobs handle regulated data, whether the DLP engine can inspect those formats, and whether a match blocks the transfer or only raises an alert.
Change control for scheduled jobs
A transfer scheduled by an unauthorized party is easy to miss if job definitions are not governed. Controls here are procedural and technical: restricting who can create or edit scheduled tasks, requiring review of new egress destinations, and keeping an inventory of jobs with their owners. Confirm that job creation is logged, that the inventory matches what runs on each host, and that a changed destination triggers a review rather than being accepted silently.
Scope of the controls
Preventive controls only protect what they can see and reach. Encrypted tunnels, unmanaged hosts and personal devices can bypass egress rules, so each control above should be mapped against your actual network paths. Ask for a written map of which segments, cloud accounts and remote endpoints route through each enforcement point, and record the gaps. Those gaps are the inputs for the detection work described elsewhere on this page.
Triage steps when a scheduled transfer alert fires
This sequence turns a scheduled transfer alert into a documented decision: whether the recurring outbound movement of data is authorized, who owns it, and what must be contained and preserved. It is designed so that the analyst can justify either closing the alert or escalating it with evidence.
Confirm the destination and owner
The first analyst on the alert identifies the destination host, domain or address, the account or service identity that initiated the transfer, and the host where it ran. They then ask the platform or application owner whether that destination is a known business endpoint, such as a backup target, a reporting partner or a managed file service. The step is complete when the analyst has a named owner for both the source and the destination, or when no owner can be found and that gap is recorded as a finding. Destinations that resolve to unfamiliar infrastructure move straight to escalation.
Correlate the scheduled job with host telemetry
The analyst pulls the scheduled task, cron entry or launchd job that is linked to the alert and compares its creation time, author and last modification against change records. They then match the job's execution times against the network connection and process creation events on the same host to confirm that the outbound session came from that job and not from an unrelated process that happened to run nearby. Output is a short timeline showing the job definition, each run and the matching network flows. If the job was created or edited outside a change window, the alert is marked for escalation.
Check against the approved transfer schedule
The analyst compares the observed schedule, volume pattern and destination with the documented business schedule for the data flow, which should be held in the change or configuration management system. Matches on time window, approximate transfer direction and destination count as authorized behavior. Differences in frequency, a new destination, or transfers outside the documented window are recorded as deviations. The step closes with a documented decision of either matches approved schedule or deviates from approved schedule, referencing the specific record checked.
Decide between closure and escalation
The incident responder reviews the owner confirmation, the job timeline and the schedule comparison together and makes a formal disposition. Alerts that match an approved schedule with a confirmed owner are closed with a note that links to the evidence. Alerts with an unknown owner, an unapproved job or an unexplained destination are escalated to incident handling and tagged as potential exfiltration. Where the decision is uncertain, the reviewer should ask a second analyst to confirm, since the same pattern can reflect both a legitimate backup and a staged theft.
Contain the unauthorized scheduled transfer
For confirmed unauthorized transfers, the responder disables the scheduled job or pauses the service account that runs it, following the change and containment procedures agreed with the platform owner. Egress to the destination is blocked at the network enforcement point, which is the control covered by the Network Intrusion Prevention mitigation (M1031) and related filtering. The step is complete when a follow-up window shows no new sessions to the destination from the source, and the containment action is recorded with its timestamp and approver.
Preserve evidence before remediation
Before the job is deleted or the host is rebuilt, the responder preserves the job definition, the scheduler and system logs, the relevant network flow records, the account's authentication history and a forensic copy of any files staged for transfer. Collection is done under the incident team's documented procedure so that chain of custody is maintained. The step is complete when the evidence set is stored in the case repository with hashes recorded and the analyst confirms that the collected items cover the full timeline from the correlation step.
Record findings and tune the detection
The analyst closes the case with a summary of the owner, schedule comparison, decision and containment, then reviews whether the alert was accurate. Repeated false positives for an approved transfer lead to an allowlist entry that names the owner and expiry date set by the team's own policy, while confirmed cases lead to updated detection content. Where a documented schedule did not exist, the finding is routed to the platform team to create one. The step is complete when the case is closed and any detection changes are logged against the ATT&CK version the rules target.
Rehearsing T1029 detection in a private cyber range
On Linux and macOS, the range should mirror the production image set: a small group of hosts running the standard build, a log forwarding agent, and an egress path that passes through the same proxy or firewall used in production. Place at least one host in a segment with direct outbound paths so the team can see what the sensors record when controls are weaker. Synthetic injects should include a recurring outbound connection created by a scheduled job or service unit that is not in the approved change record, and a second case where an approved job runs on the same schedule to the same destination class. Good detection means the team can show that scheduled job creation, the owning user, the parent process, and the network connection were correlated within the analytic window, and that the approved job was classified differently by its change reference. Good response means the on-call analyst isolates the host or blocks the destination according to the playbook, preserves the job definition and shell history before cleanup, and records whether the connection reached an external destination. Check that the exercise log names the ATT&CK version targeted for the detection mapping.
On Windows, build the range from the same Active Directory and endpoint baseline used in production, with the event forwarding and endpoint telemetry agents enabled. Include a member server and a workstation so the team can compare how scheduled task creation and network activity appear on different roles. Synthetic injects should include a scheduled task created by a non-administrative account that repeats at a fixed interval and sends data to an external host, and a matching task created by the configuration management tool that the team must recognize as authorized. Good detection means the analyst can link task registration, the principal and action of the task, and the subsequent network connection to a single host and time window, then explain why the authorized task was not escalated. Good response means the team disables the task through the approved change path, collects the task XML and the account activity for the investigation, checks whether the same task exists on other hosts, and confirms that network controls blocked or logged the destination. Avoid testing against domain controllers in a way that disrupts directory services, and confirm that rollback steps are written into the scope before the exercise starts.
The SOC response tab covers the analyst workflow across both platforms, not the endpoint build itself. The range should include the SIEM or Wazuh manager, a Security Onion or Zeek sensor on the egress path, a ticketing system, and a shared communication channel that the exercise can use without leaving the range. Synthetic injects should arrive in sequence: a low-severity alert on scheduled job creation, a network flow showing periodic outbound transfers, then a second alert that ties the two together. Vary the timing so some transfers happen outside business hours. Good detection means the analyst moves from alert to a documented hypothesis within the time the playbook sets, and states which evidence would confirm or reject it. Good response means the analyst contains the activity, requests the change record from the platform team, decides whether the event is a policy violation or a security incident, and records the decision and the evidence list in the case file. Review the exercise afterward with the platform and application owners, and record gaps as tracked actions with named owners. Confirm with the client which ATT&CK version and detection strategy identifiers the rules reference before the exercise begins.
Common questions from SOC leads and detection engineers
How do I tell a scheduled backup from T1029 activity?
Compare the scheduled job against a known-good baseline of who created it, when it runs, which hosts and destinations it touches, and how much data it moves. A legitimate backup usually has a named owner, a change record, a fixed destination that matches the backup platform, and a volume that stays within a predictable range. T1029 activity tends to show a new or modified scheduled job, a destination outside the approved backup targets, transfers at unusual hours, or a process that is not the backup agent. Build the baseline from your own environment, because a single rule rarely separates the two. Pair Network Connection Creation events with Process Creation events so each transfer is tied to the parent job and binary. Review every exception with the owner before you suppress an alert, and record the justification so auditors can follow it.
How often should I re-baseline scheduled transfer detections?
Re-baseline whenever a material change occurs, such as a backup product upgrade, a new storage destination, a change in retention windows, or a new business process that moves data on a schedule. Also schedule a periodic review, and confirm the interval with your change management owner, since your environment and regulatory obligations determine what is reasonable. Between reviews, watch for alert volume spikes and for suppressed rules that no longer match any live job. Stale exceptions are a common cause of missed activity, so expire them on a fixed cycle and require re-approval.
How do ATT&CK v20.0 changes affect my T1029 mappings?
Name the ATT&CK version in every detection record, because MITRE can rename, deprecate or revoke techniques between releases. The releases relevant to this page are v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026. ATT&CK v18 moved detections into detection strategies and analytics, so older rule documentation may point to content that no longer exists in the same form. Check the ATT&CK updates page against your current mapping, then compare the data components referenced by your rules with those in the Enterprise STIX bundle for v20.0. Keep a change log that shows which mappings you reviewed and when.
Which Sigma fields should I normalize for scheduled transfer rules?
Normalize the fields that identify the actor, the job, and the destination, because those are what analysts pivot on. At minimum, map the host name, user, parent and child process image and command line, scheduled job name and creator, destination address and port, and the transfer byte counts where your sensor provides them. Use one naming scheme across Linux, macOS and Windows so a single rule can run on each platform with platform-specific field mappings. Document each mapping in a table kept with the rule repository. Validate that the Sigma pipeline produces the same field names in your SIEM, because a silent mismatch can make a rule that looks correct never fire.
How do I test scheduled transfer rules without generating real exfiltration?
Test in a private cyber range with synthetic data and controlled, benign transfer jobs that mimic the telemetry pattern you want to detect. Define the expected alert, the expected fields and the expected response before each run, then compare the results. Use canary files and test destinations that you own, and keep the traffic within the range network so no production data leaves the environment. Replay captured telemetry from earlier exercises when possible, and log every test so the results can support later audits. DeployOpen can plan and run this kind of exercise as a fixed-scope engagement, with scope and rules of engagement agreed in writing before work starts.
Can my team run T1029 detection work without outside help?
Yes, many teams can, provided they have engineers who understand both the scheduling systems and the network telemetry in their estate. The work involves inventorying scheduled jobs on each platform, collecting Network Connection Creation, Process Creation and Network Traffic Flow data, writing and tuning rules, and running validation tests. Teams without a private range, or without staff who can own the baseline over time, often choose a fixed-scope engagement to build the first version and then keep ownership in-house. Ask any partner to state in writing which parts they will hand over, what documentation they will deliver, and what you must maintain yourself.
How DeployOpen builds T1029 detections and cyber range scenarios
DeployOpen approaches T1029 Scheduled transfer as a fixed-scope piece of work inside your own infrastructure, covering the telemetry, detection logic and cyber range exercises you need to test it. Each engagement starts with a written scope that names the platforms, data sources and ATT&CK version the detections will target.
How we scope
- Confirm which Linux, macOS and Windows hosts and network segments fall inside the T1029 detection scope.
- Inventory the Network Connection Creation, Process Creation and Network Traffic Flow sources already collected in your environment.
- Record the ATT&CK version the detection mappings target, since releases can rename or deprecate techniques.
How we build
- Write detection logic in open formats such as Sigma rules and deploy it to your Wazuh or Security Onion stack.
- Tune rules for recurring scheduled jobs and backup traffic so that expected transfers are separated from suspicious ones.
- Map Network Intrusion Prevention coverage to the T1029 detections and document any gaps in Suricata or Zeek visibility.
How we hand over
- Deliver the detection rules, data source mapping and tuning notes in a documented, version-controlled format.
- Provide a cyber range scenario that replays scheduled transfer behavior so your team can rehearse detection and response.
- Walk through the validation results and list the open items your own team needs to confirm in its environment.
How we support
- Ongoing support, upgrades and continuous testing of T1029 detections are available as a retainer.
- Retainer reviews can re-check detections when ATT&CK releases change technique mappings or data components.
- Ask any quote to state the written scope, deliverables, timelines and what recurring support is included.
