Detecting T1020 Automated exfiltration

How T1020 automated exfiltration shows up in a SOC queue

T1020 Automated Exfiltration describes an adversary moving stolen data out of a network through scripted or scheduled processing, so each transfer runs without an operator handling it by hand. MITRE places it under the Exfiltration tactic (TA0010), which ATT&CK defines as "The adversary is trying to steal data." Automated transfers usually appear after collection, when staged data is bundled and pushed by a job that repeats on a timer or fires on a trigger. This page targets ATT&CK Enterprise version 20.0, so confirm any detection mapping against that version before you adopt it, because releases can rename, deprecate or revoke techniques. The ATT&CK tactic page is the natural starting read.

In the SOC queue, this rarely arrives as an alert titled with the technique. It arrives as a steady outbound flow from a host that does not normally send bulk data, with transfer sizes that barely change between runs. The analyst typically sees a Network Connection Creation event to an external destination, a Process Creation event for the tool or script that opened it, and sometimes a Scheduled Job Creation event that explains the rhythm. Each of those looks like routine maintenance until someone asks who created the job, which account it runs under and whether the destination appears in an approved change record. Because the pattern closely resembles legitimate backup or sync jobs, the first decision is whether the environment keeps a current inventory of scheduled transfers that the SOC can check against.

Treat the first triage as a question of ownership and intent, and treat the byte counts as secondary. Confirm with the backup, sync or reporting owner whether the job is expected, then pull the job definition, the account it runs under and the change history for the host. Ask the data owner which datasets the job should touch, because a scheduled transfer that reads a directory outside its documented scope is a stronger signal than volume alone. Record the answers in the case so that a confirmed job becomes a documented baseline and an unexplained one becomes an incident. Those baseline decisions also make the cyber range rehearsal meaningful, since you can only test whether the SOC spots an unauthorized automated transfer if it already knows what an authorized one looks like.

Which telemetry reveals T1020 and which open-source tool collects it

This table maps the telemetry sources that reveal T1020 Automated exfiltration to the ATT&CK data components they relate to and to open-source collectors that can capture them. Read each row as a pairing of signal and collector, then confirm the data component IDs against the ATT&CK version your team targets before building rules. The main takeaway is that no single source is sufficient, so pair endpoint process telemetry with network and scheduled job visibility.

Telemetry source	Data component or data source	Open-source collector and what it contributes
Network Connection Creation	DC0082 (verify ID against your ATT&CK version)	Zeek connection logs or Suricata flow events show outbound sessions that recur on a fixed cadence, useful for spotting scripted uploads.
Process Creation	DC0032 (verify ID against your ATT&CK version)	Wazuh or Velociraptor can record process launches on Linux, macOS and Windows, showing which scripts or jobs start transfers.
Scheduled Job Creation	Scheduled job data source (confirm the current data component mapping in ATT&CK)	Wazuh file integrity and scheduled task or cron monitoring, with Velociraptor hunts, can reveal new recurring jobs that initiate transfers.
Network Traffic Flow	DC0078 (verify ID against your ATT&CK version)	Zeek or Security Onion flow records show byte volumes and timing per host, supporting detection of regular, automated outbound volume.
Network Traffic Content	DC0085 (verify ID against your ATT&CK version)	Suricata or Zeek protocol parsers can expose content metadata for review where your privacy and legal policies allow it.
File Access	DC0055 (verify ID against your ATT&CK version)	Wazuh or Velociraptor file access auditing can show staging of data before a scheduled transfer runs.

Detection ideas for T1020 that engineers can tune

T1020 Automated exfiltration is hard to spot because the traffic often looks like routine sync, backup or update jobs. The concepts below pair a behavioral signal with a baseline to tune against, so each rule can be adjusted to the hosts and schedules in your own environment before it reaches an analyst queue.

Recurring scheduled uploads from hosts

Look for outbound transfers that repeat at a fixed interval from the same host to the same destination, often launched by a scheduled job or cron entry created shortly before the first transfer. Tune the rule against a baseline of normal recurring jobs for each host group, and flag new destinations or intervals that appear without a matching change record. Common false positives include backup agents, endpoint telemetry shippers and patch tooling, so maintain an allowlist keyed to the job's binary path, owner and destination. Express the logic in Sigma so the same rule can be ported across log sources.

Unusual bulk outbound volume per process

Measure the bytes sent by a single process over a rolling window and compare them with that process's historical median on the same host class. A sustained spike from a process that normally sends little data, such as a text utility or a shell interpreter, is a stronger signal than total network volume alone. Set thresholds per process name and per host role, and review the top talkers weekly during tuning. Backup clients, database replication, large software updates and video conferencing are frequent sources of benign volume, so record their expected destinations to suppress them.

Data staging followed by transfer

Correlate file-creation events in a staging directory, such as a temporary archive being written, with outbound transfer from the same host within a bounded time window. The pairing is more specific than either event on its own, which matters because archiving and compression are routine on servers. Tune the window and the list of staging paths against your own file-activity baseline, and treat paths used by build systems or log rotation as known benign. Confirm that your endpoint telemetry captures file writes on the paths you intend to monitor before relying on this correlation.

Off-hours transfers from service accounts

Flag outbound data movement by service or automation accounts outside the job windows recorded for them. Compare the account's authentication and process history with its scheduled activity, and alert when a transfer occurs at a time the account has never used. Backup windows that span midnight, time zone differences and maintenance exceptions create false positives, so store the approved windows as data rather than hard-coding times into rules. Pair this concept with an inventory review of which accounts are allowed to create scheduled jobs.

New scheduled job with outbound connection

Alert when a scheduled job is created and, within a short period, the same host makes an outbound connection that the job's process initiated. The creation event alone is common during administration, so the value lies in the combination with an unfamiliar destination or a process that has not previously opened connections. Route these alerts to a review queue with the job definition attached, and confirm with the owning team before closing. Your change management records should be the first source checked for each alert.

How to validate that T1020 detections fire

This sequence proves that each T1020 detection fires on the telemetry it depends on, reaches the SOC in a usable form, and is measured for latency, false positives and missed events. It runs in a private cyber range against a named ATT&CK version so results can be repeated and compared over time.

Confirm scope and the target ATT&CK version
The security lead, the detection engineer and the range operator agree in writing on the lab boundary, the systems in scope, the test window and who can stop the exercise. They also record the ATT&CK version the rules were written against, such as the Enterprise ATT&CK version used in the detection mappings, because technique names and mappings can change between releases. The step is done when the signed scope note names the version and the stop conditions.
Define the expected telemetry for each rule
For each detection, the detection engineer writes down which data components should record the activity on each platform in scope, such as Network Connection Creation, Process Creation and Network Traffic Flow for Linux, macOS and Windows hosts. The list also states which log source carries each event and the field names the rule expects. The step closes when every rule has a one-page expected-telemetry sheet that a reviewer has signed off.
Prepare a baseline capture before the test
The range operator captures normal traffic and host activity for the same hosts before any test begins, including backup jobs, file synchronization and scheduled tasks that move large volumes of data. This baseline shows which legitimate processes could trigger the rules and gives the team a comparison set for false positives. The step is complete when the baseline is stored with its time range and the list of known benign jobs is attached to the test plan.
Run a controlled scripted transfer
An approved tester runs a scripted, time-bounded transfer of synthetic data from a lab host to a lab collection point, following the emulation plan rather than ad hoc actions. The script is run under a labeled test identity so every event can be traced to this exercise. The step is done when the run log records start and end times, the test identifier and the volume of data moved, and the range team confirms the transfer completed or stopped as planned.
Confirm the alert reaches the SOC
The SOC analyst checks the alert queue in the SIEM, such as the Wazuh dashboard or the Security Onion console, and confirms the expected rule fired with the correct host, user and time fields. The analyst also confirms the alert was routed to the right queue and carried enough context to triage without re-querying raw logs. The step closes when a ticket or case exists for the test alert and the analyst has written what they saw.
Record detection latency, false positives and missed events
The detection engineer compares the run log with the alert timestamps to calculate the delay between the transfer and the alert for each rule. They also review every alert raised during the window against the baseline to label false positives, and list any test events that produced no alert as missed events. The output is a results table per rule with latency, false positive count and missed event count. The step is done when the table is reviewed by the SOC lead.
Tune, retest and file the evidence
The team adjusts thresholds, exclusions or log collection where the results show a gap, and reruns the same emulation plan against the same ATT&CK version to confirm the change works. Final results, the baseline, the scope note and the test identifiers are stored together in the evidence repository, with the ATT&CK version recorded alongside each rule. The step is complete when a second run shows the expected result and the package is ready for internal review or a compliance assessor who asks for proof of testing.

What a scheduled exfiltration path looks like across hosts and network devices

The point of this section is that T1020 Automated exfiltration rarely shows up as one suspicious event. It appears as a chain: a scheduled job or recurring process on a host gathers data, a process hands that data to a transfer mechanism, and an outbound flow leaves through a network device. Each link may look routine on its own. Defenders need to place the three layers on one timeline, keyed by host, account and time, so that the sequence becomes visible. Before building that timeline, confirm which sources you actually collect on each layer, because a gap in any one of them breaks the chain.

Automated transfers cross several trust boundaries. The first is the boundary between the workload and the host's scheduler, where a cron entry, systemd timer or Windows scheduled task runs under a service identity that may hold broader access than any human operator. The second is the boundary between the host and the network, where egress leaves a segment that is supposed to be internal only. The third is the boundary between your environment and the destination, which may be a cloud storage endpoint, a partner system or an unmanaged host. Ask your team which of these boundaries have an owner, an approved destination list and a documented exception process. Where no owner exists, the scheduled path is the hardest to justify after the fact.

Correlating a scheduled job with outbound flows matters because either signal alone produces noise. Scheduled jobs are everywhere in administration, and outbound transfers to backup or update services are normal. The useful question is whether a job that reads from a sensitive data location is followed, within a predictable window, by a flow to a destination that is not on the approved list for that job. Plan for this correlation in advance: agree on a naming and tagging scheme for scheduled jobs, record the expected destinations for each one, and confirm that network telemetry carries enough host attribution to tie a flow back to the process that opened it. Treat any job without a documented purpose as a finding to resolve, not a permanent exception.

Preventive controls that reduce T1020 exposure

T1020 Automated Exfiltration depends on a process or tool moving data out of a host or network without much human involvement, so the preventive controls that matter most are the ones that limit what can leave, who can reach it and which paths are open. The five ATT&CK mitigations below work together: access and permissions shrink what is available to move, while network and content controls decide whether it gets through. Each card names what to confirm in your own environment before relying on it.

Data loss prevention (M1057)

ATT&CK maps Data Loss Prevention (M1057) to T1020 because automated transfers often carry recognizable content such as bulk exports, sensitive record formats or archives. DLP policies can inspect outbound content and block or alert on matches. Confirm which data classes your policies cover, whether they inspect traffic from servers and service accounts as well as user endpoints, and whether encrypted or compressed payloads are inspected or fall outside policy. Ask your DLP vendor exactly which protocols and file types it can inspect.

Network intrusion prevention (M1031)

Network Intrusion Prevention (M1031) can stop scripted or scheduled transfers that match known patterns of unusual outbound traffic, such as unexpected protocols on standard ports or repeated uploads to a single destination. Because automated exfiltration often reuses ordinary-looking protocols, inline blocking is only as good as its signatures and tuning. Confirm that the sensor sits where outbound traffic from server segments is visible, that rules cover outbound policy and not only inbound attacks, and that blocking mode is enabled for rules you have tested.

User account management (M1018)

User Account Management (M1018) limits which identities can run automated jobs, hold credentials for remote destinations or access bulk data stores. Service accounts used by backup, sync or reporting jobs are common paths for automated transfers, so they need owners, least privilege and periodic review. Confirm that every service account with outbound capability has a named owner, that interactive logon is disabled where it is not needed, and that unused accounts are removed on a fixed review cycle.

Restrict file and directory permissions (M1022)

Restrict File and Directory Permissions (M1022) reduces what an automated process can collect in the first place. When staging directories, backup targets and export folders are readable by broad groups, any job running under those groups can gather and move data. Confirm that sensitive directories grant read access only to the processes that need it, that world-readable staging paths are absent from servers holding regulated data, and that permission changes are logged so drift can be detected.

Filter network traffic (M1037)

Filter Network Traffic (M1037) covers egress rules that decide which destinations and ports servers can reach. Default-deny outbound policies for server subnets stop many automated transfers before they start, while allow lists limit where legitimate jobs can send data. Confirm that outbound rules are reviewed against documented job destinations, that DNS and proxy paths are not an unmonitored bypass, and that exceptions carry an owner and an expiry date.

Triage and response when a T1020 detection fires

The first task when a T1020 detection fires is to establish whether a scheduled job or process is moving data on purpose. Identify the owner of the job or process from the host's scheduler configuration, its change history and the account it runs under, then confirm with that owner, in writing, whether the transfer was expected. Next, compare the destination against your allowlist of approved storage endpoints, backup targets and partner transfer hosts. A destination that is not on the list, or a recognized host reached at an unusual time or volume, moves the alert from a probable administrative change to a suspected incident. Record the decision and the evidence used, because the same record will be needed for later review.

Preserve volatile evidence before you change anything. Capture the running process list, active network connections, the scheduler entries and their last-modified times, and the contents of the script or unit file that performed the transfer. On Linux, copy the relevant cron or systemd timer definitions and the shell history for the executing account. Then scope the problem: search your telemetry for the same job name, hash or destination across other hosts, and check whether the job was created recently or inherited from a golden image or configuration management run. Treat any host where the job was not authorized as potentially compromised until the scope is known.

Containment should follow business impact. Disabling the job stops the transfer but may break a legitimate backup or reporting flow, so agree a containment choice with the service owner first. Options include pausing the scheduler entry, blocking the destination at the egress firewall or proxy while leaving the host running, or isolating the host when the job is confirmed malicious. Keep the job definition and network logs intact so that the investigation can reconstruct what left the environment. Notification duties depend on your client's own policy, data classification and applicable regulation, so confirm with the privacy, legal and compliance owners what triggers notification and within what timeframe. Your incident runbook should name those owners in advance, not during the event.

Rehearsing T1020 detection in a private cyber range

This tab covers a private range of Linux and Windows hosts that mirror the client's build standards, with logging agents, a Wazuh or comparable manager, and a Zeek or Suricata sensor on the segment. The goal is to confirm that process and connection telemetry for T1020 is complete enough to reproduce a scheduled or repeated outbound transfer pattern. Exercise designers should use a scripted, benign data movement that the blue team does not know about in advance, and record what the host telemetry shows at each stage.

Baseline injects: Run ordinary backup jobs, log shipping, patch downloads and file synchronization for several days so analysts learn what routine outbound transfers look like on each host class.
Detection target: Repeated outbound flows from an unexpected process at predictable intervals, correlated with a process creation event and a scheduled job creation event on the same host.
Telemetry check: Confirm that the Sigma or Wazuh rules fire on the expected data components, and that the process ancestry is preserved in the alert.
Response target: Analysts isolate the host, preserve volatile evidence and identify the scheduled job owner within an agreed window that the team sets before the exercise.
Scoring: Record false positives against the baseline set, not against a generic rule pack.

Check that each detection was tested on a build matching production, and that the range results are documented against the ATT&CK version the rules target.

Questions SOC leads ask about T1020 detection

How do I separate T1020 automated exfiltration from legitimate backup jobs?

Start by building an inventory of scheduled backup and sync jobs, including their hosts, service accounts, destinations and expected transfer windows, then treat anything outside that baseline as a lead. Backup traffic usually goes to a known repository or cloud target, runs under a named service account and follows a predictable schedule, while automated exfiltration tends to show new destinations, unfamiliar parent processes or off-hours bursts. Use Process Creation and Scheduled Job Creation telemetry to confirm who launched the job, and Network Connection Creation to check the destination. Document the exceptions in your tuning notes so analysts can see why a rule stayed quiet.

How often should we retest T1020 rules after an ATT&CK release?

Retest whenever you adopt a new ATT&CK version, because releases can rename, deprecate or revoke techniques and change the detection guidance attached to them. The ATT&CK updates pages list recent releases, including v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026, so check the release notes for the version your rules target. Record the ATT&CK version in each detection's metadata, and rerun your cyber range scenarios after any change to log sources or rule logic, not only after ATT&CK changes.

Which data sources for T1020 are missing most often?

In most environments the gaps are in Scheduled Job Creation on non-Windows hosts, in process telemetry from servers that run cron or systemd timers, and in network flow records from segments behind proxies or load balancers. Without the host-side record, you can see a large outbound transfer but not the job that created it. Confirm each source in a short coverage check: generate a known scheduled job, confirm the event appears in your SIEM with the expected fields, and note any hosts where it does not. Treat missing coverage as a finding to report, not as a reason to drop the technique from your plan.

How should we tune thresholds for T1020 without creating alert fatigue?

Set thresholds from observed baselines for each host group rather than from a single global number, and start in a detect-only mode so analysts can review hits before paging anyone. Tune on the combination of signals, such as a new destination, an unusual parent process and an off-hours schedule, because any one signal alone is noisy. Keep a log of every threshold change with the reason and the date, and review false positives weekly for the first few cycles. Your cyber range is the safe place to test whether a new threshold still catches the scenario you rehearsed.

Can our own team run T1020 detection without an outside partner?

Many SOC teams can, provided they already run a SIEM, collect Linux, macOS and Windows endpoint logs and have analysts who can read process and network events. The harder parts are maintaining baselines for scheduled jobs across many hosts, retesting rules after ATT&CK releases and running regular exercises that prove the detection works. Ask yourself whether those three activities have an owner and time in the plan. DeployOpen implements open-source detection stacks inside your own infrastructure and runs cyber range exercises under a written, fixed scope, so teams can choose to hand over a defined part of this work.

What should we ask a vendor or partner before we rely on T1020 alerts?

Ask which log sources and fields the detection depends on, which ATT&CK version the rules target and how they were validated. Request a sample of the alert output, the tuning history and the test cases used in a cyber range, and confirm who maintains the rules after go-live. Check whether the work includes retesting after ATT&CK releases and documenting coverage gaps for auditors. Avoid relying on any claim you cannot trace to a log, a test result or a written deliverable.

How DeployOpen builds T1020 detections and range scenarios

DeployOpen approaches T1020 Automated exfiltration as a fixed-scope piece of defensive work inside your own environment. We agree what is covered in writing, build and test the detections against telemetry you already collect or can collect, and hand over documentation your team can operate without us.

How we scope

The written scope names the platforms, such as Linux, macOS, Windows and network devices, covered for T1020.
Scope lists the telemetry sources to be used, such as network connection, process creation and scheduled job creation logs.
Scope states the ATT&CK version targeted, so detection mappings stay tied to a named release.

How we build

Detection logic for T1020 is written in plain language first, then expressed in open-source rule formats such as Sigma.
Rules are deployed to your Wazuh, Security Onion or other chosen stack, using log sources you already operate.
Each detection is tested against benign administrative activity to measure false positives before handover.

How we hand over

You receive detection documentation mapping each rule to the T1020 data components and the targeted ATT&CK version.
A private cyber range scenario is delivered so your analysts can rehearse detection and response for T1020.
Runbooks cover triage, containment and evidence collection steps, written for your own response team.

How we support

Ongoing support, rule tuning and periodic re-validation are available as a retainer after handover.
Retainers can cover ATT&CK version updates, since releases can rename, deprecate or revoke techniques.
Continuous testing of T1020 detections can be added to a retainer, with scope agreed in writing.

T1020 Automated exfiltration