ATT&CK T1020 Automated Exfiltration: Detection Guide

Automated Exfiltration (T1020) is data theft that runs without a human at the keyboard: a script, scheduled job, implant module, API loop or mirrored traffic stream that keeps sending data out once it is set up. MITRE ATT&CK v20 places it under Exfiltration on Linux, macOS, Network Devices and Windows, with one sub-technique, Traffic Duplication (T1020.001), covering abuse of traffic mirroring on network devices and in cloud networks. Because automation repeats, it leaves patterns that one-off theft does not: regular timing, consistent destinations, and configuration that persists. This guide covers how automated exfiltration shows up, the ATT&CK analytics, cloud and network mirroring controls, prevention, response and metrics. It is for detection engineers, SOC analysts and cloud and network administrators. For the full picture of exfiltration channels see the Data Exfiltration Guide.

Key takeaways

T1020 describes how the theft is driven, not the channel. ATT&CK notes that other exfiltration techniques usually apply as well, such as Exfiltration Over C2 Channel (T1041) or Over Alternative Protocol (T1048), so detect the automation and the channel together.
Regularity is the signal. ATT&CK records tools sending collected files every 60 minutes and a script running every 10 minutes; fixed intervals to one destination stand out against human activity.
The scheduler is evidence. ATT&CK's analytics pair a scheduled task, cron job or launchd item with repeated outbound connections from the same process.
Traffic mirroring is exfiltration by configuration. On cloud networks and network devices, one mirror session can copy every packet from a workload to a collector the attacker controls, with no malware on the source.
Machine identities do the work. API keys, service accounts and tokens with bulk read rights turn automated theft into a few API calls, so scope and monitor them.

How automated exfiltration shows up

ATT&CK v20 defines T1020 as exfiltrating data, such as sensitive documents, through automated processing after it is gathered during Collection. It usually follows Automated Collection (T1119) and often combines with Scheduled Transfer (T1029) and Data Transfer Size Limits (T1030). The procedure examples show four common patterns.

Pattern	ATT&CK examples	What defenders see
Implant module that uploads whatever it collects	Gamaredon Group modules uploading gathered documents to C2; Rover searching drives for listed extensions and sending files every 60 minutes	A process repeatedly sending outbound data at fixed intervals, often matched to file reads of office documents
Scheduled script	Kimsuky running a script every 10 minutes that exfiltrates staged files once they appear; RedCurl batch scripts	A scheduled task or cron entry launching an interpreter that makes outbound connections
Bulk API extraction from SaaS or databases	The Salesforce Data Exfiltration campaign (C0059) using API queries to extract large volumes of data; the AI-Assisted Breach of Mexico's Government Infrastructure (C0064), where an AI coding agent was tasked to export millions of database rows as CSV files	Unusual query volume or export jobs from one identity, often outside business hours or from a new IP address
Traffic duplication	Salt Typhoon enabling traffic mirroring to exfiltrate data (T1020.001)	New SPAN, ERSPAN or cloud mirror sessions, and flows from a mirrored interface to an unfamiliar target

ATT&CK also records automated exfiltration to removable media from air-gapped systems by USBStealer and Tropic Trooper; see the Removable Media and USB Control Guide for that path.

Detection: ATT&CK's analytics for T1020

ATT&CK v20 attaches the Automated Exfiltration Detection Strategy, with one analytic per endpoint platform.

Platform	What the analytic looks for	Log sources ATT&CK names
Windows	Automated tools or scripts periodically sending data to external destinations through scheduled tasks or background processes	Security event 4688 process creation; Sysmon event 3 network connections and event 22 DNS queries
Linux	Background scripts, for example run by cron, or daemons repeatedly sending data to remote addresses or URLs	auditd execve records; network flow records of outbound connections
macOS	LaunchAgents or LaunchDaemons making periodic external connections that suggest automated transfer	Unified log process and network events; cron and launchd job creation

Turning the analytics into rules

Start from the scheduler: list scheduled tasks, cron entries and launchd items created in the last 30 days whose action runs an interpreter (PowerShell, cmd, Python, bash, osascript) or a binary in a user-writable path. See the MITRE ATT&CK T1053 Scheduled Task/Job guide.
Link the job to the network: join process creation from those jobs to Sysmon 3 or flow records and keep the ones with external destinations.
Score periodicity and volume: connections from one process to one destination at a near-constant interval, with bytes out larger than bytes in, are the automated exfiltration shape. The same scoring used for beacons applies; see the Beaconing and C2 Detection Guide.
Add file context: on Windows and macOS, a process that reads many documents and then makes outbound connections is far more suspicious than one that only connects.
Cover SaaS and databases separately: endpoint analytics do not see API extraction. Alert on export jobs, report downloads and query volumes that exceed a per-identity baseline in the SaaS or database audit log. For one example see the Salesforce Event Monitoring Detection Guide.

Traffic Duplication (T1020.001) in cloud networks

ATT&CK describes T1020.001 as abusing traffic mirroring to automate exfiltration over compromised infrastructure, on Network Devices and IaaS. It notes that AWS Traffic Mirroring, GCP Packet Mirroring and Azure vTap let users choose instances to collect traffic from and targets to send it to, and that adversaries may combine duplication with Network Sniffing (T1040), Input Capture or Adversary-in-the-Middle. The cloud services are listed alphabetically below; each is a legitimate monitoring feature, and the controls are customer-side permissions and logging.

Service	What it mirrors and where to	Permission to restrict	What to monitor
AWS Traffic Mirroring	Traffic from a source elastic network interface, selected by a filter, to a target instance or a fleet behind a Network Load Balancer or Gateway Load Balancer with a UDP listener; a session links source, filter and target	EC2 traffic mirror actions in IAM policies	CloudTrail CreateTrafficMirrorSession and related target and session changes; VPC flow logs on the mirror target (ATT&CK's IaaS analytic)
Azure virtual network TAP (public preview as of November 2026)	Traffic from VM network interfaces to a VM interface or internal load balancer in the same or a peered virtual network	Microsoft.Network/virtualNetworkTaps/* and Microsoft.Network/tapConfigurations/* actions, included in Network Contributor	Activity log entries for TAP resources and TAP configurations on interfaces
Google Cloud Packet Mirroring	Full packets from VMs selected by subnet, network tag or instance name, to a collector instance group behind an internal passthrough Network Load Balancer	compute.packetMirroringAdmin on mirrored sources; compute.packetMirroringUser in the collector's project	Admin activity audit logs for packet mirroring policy changes

Restrict who can mirror: ATT&CK's M1018 User Account Management guidance is not to grant permissions to create or modify traffic mirrors unless explicitly required. Remove mirroring actions from broad roles and grant them to a named network monitoring role only.
Alert on every new mirror session: mirror sessions change rarely in most estates. Treat any creation or target change outside a change ticket as high priority, and check that the target belongs to your own monitoring tooling.
Watch cross-account and cross-project targets: Google Cloud documents cross-project mirroring with roles in each project, and Azure allows peered networks. A target in a project or network you do not recognise is the key question.
Encrypt in transit: ATT&CK's M1041 Encrypt Sensitive Information reduces what a mirror reveals. Mirrored TLS traffic exposes metadata, not content.

Google Cloud notes that VPC Flow Logs do not log mirrored packets, although traffic sent directly to a collector on a subnet with flow logs is logged. Rely on the control-plane audit log, not flow logs, to detect a new mirror.

Traffic Duplication on network devices

The joint advisory on Chinese state-sponsored actors led by NSA, CISA, FBI and DC3 with international partners (first published 27 August 2025, v1.1 3 September 2025) reports actors enabling traffic mirroring through SPAN, RSPAN or ERSPAN on compromised devices and using on-box packet capture to collect TACACS+ traffic on TCP 49. Its hunting guidance includes alerting on any on-box packet capture start, continuously watching monitor session and capture state, comparing running configurations with the latest authorised versions, and watching FTP or TFTP flows from devices to unapproved destinations. It recommends AAA command accounting so capture commands are recorded, and blocking egress from the management network except to authorised collectors. The detection rules and configuration checks are covered in depth in the Network Device Syslog and Configuration Change Detection Guide and the Salt Typhoon Threat Actor Profile.

Prevention

ATT&CK lists no mitigations against the parent technique, because automation is a property of the theft rather than a separate channel. Prevention therefore comes from the collection and channel controls around it, plus the three mitigations listed for T1020.001: M1041 Encrypt Sensitive Information, M1018 User Account Management and M1057 Data Loss Prevention.

Constrain egress: servers and service hosts should reach only named destinations through a proxy or firewall allowlist. Automated exfiltration depends on a stable outbound path. See the Cloud Egress Filtering guide.
Control scheduled jobs: limit who can create scheduled tasks and cron jobs on servers, and alert on new ones. Application control stops many scripts and implants from running at all.
Scope bulk read rights: machine identities with export, report or database-wide read permissions are the engine of API extraction. Remove bulk export from integrations that do not need it and require separate approval for data exports.
Rate-limit and cap exports: where a SaaS platform or database supports per-identity query limits or export restrictions, set them to the documented business need.
Lock down mirroring: remove mirror permissions from broad cloud roles, restrict SPAN and capture commands on network devices through AAA command authorisation, and keep device management on an isolated network.
Apply DLP at the egress point: ATT&CK's M1057 suggests DLP to detect and block unauthorised transfers of sensitive data. See the Data Loss Prevention (DLP) Guide.

Where to start

Environment	First control	Trade-off
Windows and Linux servers	Egress allowlisting and alerts on new scheduled jobs with network activity	Initial effort to document legitimate outbound flows
IaaS	Remove mirror permissions from broad roles and alert on mirror session changes	Network teams need a named role and change process for legitimate monitoring
Network devices	AAA command accounting, configuration diffing, management network egress block	Needs a configuration baseline and change discipline
SaaS and databases	Per-identity export baselines and least-privilege integration scopes	Audit log retention and licensing may limit visibility

Where identity fits

Automated exfiltration usually runs as a machine identity: a service account behind a scheduled job, an API key or OAuth token behind a SaaS export, a cloud role that can create mirror sessions, or a device account with capture privileges. Each should have the narrowest rights its job needs, an owner, and monitoring for use from new locations. When automated theft is found, rotate every credential the automation used, because the attacker may have copied them for later use. See the Service Account Behavioural Baselining Guide.

Responding to automated exfiltration

Stop the automation and the path together: disable the scheduled job, mirror session or integration, and block the destination at the egress point. Stopping only one lets the other continue.
Preserve the configuration first: export the task definition, cron entry, mirror session or device configuration before removing it. It records the destination, schedule and filter, which define what was taken.
Size the loss: use the schedule and flow records to estimate how long the automation ran and how much left. For mirroring, the filter and source interfaces define the data exposed.
Revoke and rotate: disable the identity that ran the automation and rotate any credentials visible in mirrored traffic or on the source host.
Assess notification duties: if personal data left, data protection rules may require notification. Follow the Data Exfiltration Playbook.

Metrics that show it is working

Scheduled jobs with external network activity: count on servers, each with an owner. Target a stable, documented list.
Mirror permission holders: identities able to create or modify cloud traffic mirrors. Target a small named set.
Unapproved mirror sessions: sessions found that lack a change record. Target zero.
Server egress coverage: share of servers whose outbound traffic is restricted to an allowlist.
Export baseline coverage: share of critical SaaS and database platforms with per-identity export alerting.

Framework mapping

Control area	NIST SP 800-53 Rev 5	NIST CSF 2.0	ATT&CK
Egress restriction	SC-7 Boundary Protection	PR.IR-01	Related channel techniques T1041, T1048
Restrict mirroring and bulk read rights	AC-6 Least Privilege; AC-2 Account Management	PR.AA-05	M1018 User Account Management
Encryption in transit	SC-8 Transmission Confidentiality and Integrity	PR.DS-02	M1041 Encrypt Sensitive Information
Data loss prevention	SC-7(10) Prevent Exfiltration	PR.DS-02	M1057 Data Loss Prevention
Configuration baselines for devices	CM-2 Baseline Configuration; CM-3 Configuration Change Control	PR.PS-01	Detection strategy for T1020.001
Monitoring	SI-4 System Monitoring; AU-6 Audit Record Review, Analysis, and Reporting	DE.CM-01; DE.CM-09	Detection strategy for T1020

Common failure patterns

Looking only for large transfers: automation often moves small amounts on a schedule, under volume thresholds.
Ignoring the cloud control plane: mirror sessions are created through APIs, and flow logs do not show mirrored packets.
Granting network roles broadly: broad network administration roles can include mirroring rights nobody intended to grant.
Endpoint-only visibility: API extraction from SaaS or databases never touches a monitored endpoint.
Deleting the job before recording it: the schedule and destination are the best evidence of scope.

Practitioner checklist

Inventory scheduled tasks, cron and launchd jobs on servers that make external connections, and assign owners.
Build the ATT&CK T1020 analytics: scheduler, process and network joined, scored for periodicity and bytes out.
Restrict server egress to named destinations through a proxy or firewall allowlist.
Remove cloud traffic mirroring permissions from broad roles and alert on every mirror session change.
Turn on AAA command accounting and configuration diffing for SPAN, ERSPAN and capture commands on network devices.
Baseline per-identity export and query volumes on critical SaaS and database platforms.
Scope integrations and service accounts to the minimum read rights they need.
Rehearse response: stop job and path, preserve configuration, size loss, rotate credentials.

MITRE ATT&CK T1020 Automated Exfiltration: Detecting Scripted Data Theft and Traffic Mirroring