Data Exfiltration Response Playbook
Detecting and scoping data exfiltration — what was taken, how much, and to where — and how to answer the question regulators will ask: "Do you know what data was in those files?"
Your DLP fires: 8 GB of data transferred to an IP address in Eastern Europe over the past 4 hours. The traffic is encrypted HTTPS. The source is a database server. You have two problems: stopping any ongoing exfiltration, and answering the question your CISO, lawyers, and eventually regulators will ask — "What data was in those 8 GB?" That question determines whether this is a reportable breach, whether you have regulatory notification obligations, and how much the incident will cost. This chapter covers both the technical stop and the data classification investigation.
Stopping Ongoing Exfiltration
Exfiltration Response Priority Order
═══════════════════════════════════════════════════════════════════
STOP the outbound transfer first, then investigate what left.
Don't investigate while exfiltration is continuing.
T+0:00 Block the destination IP at the perimeter firewall
(fastest action — stops the pipe before isolating the source)
T+0:05 Identify the process on the source system doing the transfer
(netstat -anob or Get-NetTCPConnection — what process owns the connection?)
T+0:10 Isolate the source system via EDR
(belt-and-suspenders: firewall blocks the IP, EDR blocks the host)
T+0:15 Preserve: network flow data, packet capture if available,
process memory snapshot for the exfiltrating process
T+0:30 Begin determining what was transferred (the hard part)
# Identify active large outbound data transfers
# Run on the suspected source host or query EDR/firewall logs
# On-host: current connections sorted by bytes (live view)
Get-NetTCPConnection -State Established |
Where-Object { $_.RemoteAddress -notmatch "^(10\.|192\.168\.|172\.)" } |
ForEach-Object {
$proc = Get-Process -Id $_.OwningProcess -EA 0
[PSCustomObject]@{
RemoteIP = $_.RemoteAddress
RemotePort = $_.RemotePort
PID = $_.OwningProcess
Process = if ($proc) { $proc.Name } else { "?" }
Path = if ($proc) { $proc.Path } else { "?" }
}
} | Format-Table
# SIEM query: identify which source IPs have high outbound bytes to external IPs
# (Network flow / Zeek / NetFlow source)
# Splunk example:
# index=network_flow earliest=-4h
# | where src_ip LIKE "10.%" AND NOT (dest_ip LIKE "10.%" OR dest_ip LIKE "192.168.%")
# | stats sum(bytes_out) as total_bytes by src_ip, dest_ip
# | sort -total_bytes
# | where total_bytes > 100000000 (>100MB)Determining What Data Was Exfiltrated
This is the hardest part of any data exfiltration response. The transfer was encrypted — you can't look inside the packets. You have to reconstruct what was taken from what the attacker accessed before the transfer.
| Evidence source | What it tells you | Limitation |
|---|---|---|
| File server access logs (Windows Security Event 4663) | Which files were accessed by which account in the time window before exfiltration | Must have object access auditing enabled; doesn't tell you if the file was read vs. just opened |
| Database query logs | Which tables/rows were queried; how many records returned | Requires query logging enabled (performance impact means it's often off by default) |
| DLP event details | If DLP performs content inspection: what data patterns were detected in the outbound transfer | Encrypted transfers bypass most DLP unless TLS inspection is deployed |
| CASB logs (for cloud storage exfiltration) | Exact files uploaded to cloud storage services | Only covers managed cloud services; attacker-hosted cloud storage is transparent |
| Staging directory artifacts | What the attacker collected before transferring — look for ZIP/RAR archives, temporary directories with unusual names | Attacker may have deleted staging artifacts; check VSS copies if available |
| Memory analysis of exfiltrating process | In-memory copies of data in the process at time of collection | Requires memory acquired before or during exfiltration; partial data only |
# Identify files accessed by a suspect account before exfiltration
# Requires: Windows Security Audit Policy — Object Access: File System = Success
$account = "jsmith"
$startTime = [DateTime]"2026-08-28T20:00:00" # 4h before exfiltration detected
$endTime = [DateTime]"2026-08-29T00:00:00"
# Event 4663 — Object access (file accessed)
$fileServer = "SERVER-FILES01"
Invoke-Command -ComputerName $fileServer -ScriptBlock {
param($acct, $start, $end)
Get-WinEvent -FilterHashtable @{
LogName = "Security"
Id = 4663
StartTime = $start
EndTime = $end
} -ErrorAction SilentlyContinue | ForEach-Object {
$xml = [xml]$_.ToXml()
$d = $xml.Event.EventData.Data
$who = ($d | Where-Object Name -eq "SubjectUserName")."#text"
if ($who -eq $acct) {
[PSCustomObject]@{
Time = $_.TimeCreated
File = ($d | Where-Object Name -eq "ObjectName")."#text"
Access = ($d | Where-Object Name -eq "AccessMask")."#text"
}
}
}
} -ArgumentList $account, $startTime, $endTime -ErrorAction SilentlyContinue |
Where-Object { $_ } |
Sort-Object Time |
Export-Csv "file_access_audit.csv" -NoTypeInformationRegulatory Breach Determination
The data classification of what was exfiltrated determines whether you have a reportable breach. This determination must involve legal counsel.
| Data type found in accessed files | Likely notification obligation | Consult |
|---|---|---|
| PII (name + SSN/DOB/financial account number combinations) | State data breach notification laws (US) — typically 30-90 days; GDPR if EU residents (72 hours) | Outside counsel + DPO |
| Protected Health Information (PHI) | HIPAA Breach Notification Rule — covered entity must notify HHS and affected individuals within 60 days | HIPAA compliance officer + outside counsel |
| Payment card data (PAN, CVV, expiry) | PCI DSS forensic investigation required; card brand notification via acquiring bank | QSA + acquiring bank |
| Employee records | State laws vary; HR and Employment counsel; some states require employee notification | HR + Employment counsel |
| Trade secrets / proprietary IP (no personal data) | No statutory notification obligation, but civil litigation and IP protection actions may apply | IP counsel |
Regulatory frameworks (GDPR, HIPAA, state breach notification laws) require a determination of what data was involved — not a guess, and not "we couldn't tell." If you genuinely cannot determine what data was in the exfiltrated transfer from available evidence, the legal default in most jurisdictions is to assume the worst: if the attacker had access to a file server containing PII, assume PII was exfiltrated and apply the notification obligation. This is why investment in file access auditing, DLP with content inspection, and database query logging — which feel expensive before an incident — pays off when you need to answer this question definitively rather than conservatively. "We can confirm X files were accessed and they contained Y data" is a much better position than "we can't confirm what was taken."
Q & A
Q: The exfiltration used a cloud storage service (Dropbox/Box/OneDrive personal account). Is the data still recoverable?
Possibly — through legal process. Law enforcement can serve a legal process (subpoena or court order) on the cloud storage provider to preserve and produce the uploaded content. This requires: (1) confirmed evidence that specific data was uploaded (CASB logs, proxy logs showing upload, or the attacker's local staging directory showing what was uploaded and to where), (2) engagement with law enforcement who can file the legal process, and (3) time — the provider must preserve the data before the attacker deletes it. For a civil case or for a self-help recovery without law enforcement involvement, cloud providers generally will not disclose account contents without legal process. Contact your outside counsel and — if criminal activity is involved (ransomware, trade secret theft) — file a report with the FBI Cyber Division to initiate the preservation request as quickly as possible.
Q: You believe 2 GB of data was exfiltrated. It came from a share that contains 500,000 files across many categories including PII, non-PII business data, and no-sensitivity internal documents. How do you scope the notification obligation?
Work backwards from what the attacker actually accessed. The 2 GB transferred represents a fraction of the 500,000-file share. Use file access audit logs (Event 4663) to identify the specific files accessed in the time window, and classify those files. You're not required to notify about files that were on the same server but not accessed — only about data that was actually accessed and potentially exfiltrated. If file access logging wasn't enabled and you can't determine which specific files were accessed, your legal default is to classify based on what the share contained (if it contained PII, assume PII was exfiltrated). This is the argument for enabling object access auditing before incidents, not after — the audit log is the difference between a targeted notification and a blanket "we accessed your data" notification to everyone in the database.