What Is Data Exfiltration? Ten Ways Attackers Take Data Out, Three Cases From This Week That Show Where You Could Have Caught It, and Five Controls
If you only do one thing about data exfiltration this week, put a rate limit on every internal API that returns records and alert on any outbound connection from your build system to a service you did not choose. Data exfiltration is an attacker moving data out of your environment to somewhere they control. It is usually the step that turns a break-in into a breach, and it is also the step that is easiest to notice if anything is counting.
What is data exfiltration?
MITRE ATT&CK, the public catalog of attacker behavior, defines the exfiltration tactic in one line: the adversary is trying to steal data. It sits near the end of an intrusion. The attacker has found something worth taking and now has to get it out without being stopped.
How do attackers take data out?
MITRE lists ten top-level techniques under that tactic. In plain terms:
- Over the attacker's existing command channel, so the data rides the same connection that controls the malware.
- Over an alternative protocol, whether encrypted or not, that is different from the command channel.
- Over a web service, which includes code repositories, cloud storage, text-storage sites and webhooks. The traffic looks like ordinary use of a popular site.
- To a cloud account the attacker controls.
- Automatically, including by duplicating traffic, or on a schedule.
- In small chunks that stay under a size limit, so no single transfer looks large.
- Over another network medium such as Bluetooth, or on physical media such as a USB drive.
- AI-enabled exfiltration, a technique MITRE lists in its current catalog. We read only the name and did not read its detail page.
The common feature is that the data leaves by a route that looks normal. That is why the controls below focus on rates, new accounts and destinations, not on content.
Three cases from this week
These are the organizations' own accounts, and we have not verified them independently.
LiteLLM, October 10. LiteLLM's root-cause analysis says workflows pushed to temporary branches sent six repository secrets to a webhook.site endpoint, and the run records were deleted within three minutes. A second workflow sent another maintainer's release token to the same place 24 seconds later. That is exfiltration over a webhook, and the deletion of the runs was an attempt to remove the evidence. We wrote the full chain in "LiteLLM's Root-Cause Report Says the Poisoned Release Began With an Admin Key Committed to a Public Repo."
WorkOS, October 25 to 30. WorkOS says an AI agent run by a researcher pulled records in bulk from an internal sales tool that sat on the public internet, accepted a predictable development credential and had no rate limits. WorkOS noticed an unusually high volume of CRM queries on October 30, five days after first access. It says the researcher deleted the data. WorkOS has not said how many customers were affected, and the deletion claim is the researcher's.
DigiCert, June 27 to July 2. DigiCert says accounts created through a self-registration page that became reachable after a server migration could read an archive of customer information for five days. The report says the system had no alerts for new accounts or unusual request volume, and DigiCert first suspected data access on October 12. This is closer to exposure than to classic exfiltration, but the lesson is the same: nothing was counting.
Where can you catch it?
- At the API. A bulk pull shows up as an unusual query rate. WorkOS saw it, but five days late, and it had no limit that would have slowed it.
- At new identities. DigiCert's accounts were created through an open page and nobody was alerted to new accounts.
- At outbound connections. A build job that talks to a public webhook service is unusual in most organizations, and easy to alert on once you decide to.
- At the logs themselves. LiteLLM's attacker deleted workflow runs within minutes. A deleted run is a signal worth alerting on.
What to do this week
- Put rate limits and alerts on every internal API that returns records, including tools meant only for staff. Assume an automated client is faster than any person.
- Restrict what build and CI systems can reach on the internet, and alert on connections to webhook, paste and public storage services.
- Alert on newly created accounts and on bulk reads, especially against archives.
- Alert on deleted workflow runs, deleted audit entries and overridden branch protections.
- Keep secrets short-lived and scoped, so a stolen one is worth less. Truffle Security reported on November 4 that leaked keys often stay valid for months.
Indicators
None. This is an explainer on a tactic, so we added nothing to the feed.
Limits
The technique list is MITRE's, as shown on its tactic page. The three cases are the organizations' own accounts. We did not verify WorkOS's deletion claim, DigiCert's scope or any customer impact. We did not test any detection. The controls are our suggestions, and none is a guarantee.
Five percent of this is wrong somewhere. It always is. The organizations' own follow-ups could change a date or a figure.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.