Data Exfiltration Investigation

This runbook is the family-specific continuation of Critical Alert Triage for any alert whose evidence points at unauthorized outbound data transfer. It covers the principal trigger — a Data Exfiltration Detection Alert on the Hunt page — and the secondary trigger a threat hunter encounters during routine review when an unusually high client-to-server byte ratio stands out on the Netflows bucket or on a future Producer-Consumer Ratio widget on the Dashboard. Either path routes into this runbook, and the steps below take the analyst from "an alert with exfiltration-shaped evidence" to "a triage decision recorded in the incident-management system".

This runbook is written for Tier 1 Security Operations Center (SOC) analysts performing first-response triage on outbound-traffic alerts, Tier 2 analysts resolving escalations, and threat hunters pivoting from an unusual upload pattern into a broader compromise investigation. It assumes the analyst has already executed Critical alert triage through step 5 when the lead originated from a Critical-severity alert — the affected asset, the supporting sidebar evidence, the repetition history, and any same-flow corroboration are already in hand.

First-use acronym expansions in this runbook: SOC (Security Operations Center), IOC (Indicator of Compromise), C2 (command-and-control), IP (Internet Protocol), DNS (Domain Name System), TLS (Transport Layer Security), SNI (Server Name Indication), ASN (Autonomous System Number), GeoIP (geographical IP lookup), RFC-1918 (the Internet Engineering Task Force standard reserving private IP ranges), MB (megabyte — 1,048,576 bytes), TIDB (Threat Intelligence Database), REPDB (Reputation Database), PCR (Producer-Consumer Ratio), PCAP (packet capture), HTTPS (Hypertext Transfer Protocol Secure), HTTP (Hypertext Transfer Protocol), FTP (File Transfer Protocol), SSH (Secure Shell), SFTP (Secure File Transfer Protocol), SMB (Server Message Block), TCP (Transmission Control Protocol), S3 (Simple Storage Service), SaaS (Software-as-a-Service), CI (continuous integration), EDR (endpoint detection and response), DLP (Data Loss Prevention), NAT (Network Address Translation), IR (incident response), MVP (Minimum Viable Product), FRD (Functional Requirements Document).

Trigger Scenario

An analyst reaches this runbook from one of two starting points. In either case the lead describes an internal host sending materially more bytes to an external endpoint than it received.

Primary — Data Exfiltration Detection Alert on the Hunt page. The analyst opens the Hunt Page, navigates to the All Alerts bucket, and selects the Data Exfiltration Detection Alert sub-tab. A row carries a flow_count, a total_upload_bytes measured in tens or hundreds of megabytes, a total_download_bytes measured in tens of megabytes or less, an upload_ratio above 2:1, a 15-minute window, and a destination country / ASN / organization. The severity may be Critical, High, Medium, or Low depending on the ratio, the absolute upload volume, and whether an IOC has matched on the destination.
Secondary — unusually high upload ratio spotted during proactive review. During a routine pass through the Netflows bucket, the analyst sorts by bytes_toserver descending and notices a flow (or a group of flows to a single destination) where the client-to-server byte count dwarfs the server-to-client count. Analogous leads surface from the Top Destination IPs widget on the Dashboard when an unfamiliar external destination jumps to the top of the chart; the dedicated Producer-Consumer Ratio (PCR) widget listed in the Dashboard roadmap will expose this pattern directly when it ships.

The two trigger surfaces converge in this runbook because the investigation is the same: an internal host is uploading enough data to an external endpoint that the pattern has to be accounted for. A Data Exfiltration Detection Alert on its own attaches the pipeline's windowed aggregate and severity tier; an upload-ratio lead from Netflows or the Dashboard lacks the aggregate but surfaces the same behavior at the raw-flow level. The evidence-gathering steps are identical once the analyst is in the Hunt workspace.

Prerequisites

Before executing this runbook the analyst confirms the following.

Steps 1 through 5 of Critical Alert Triage are complete when the lead is a Critical-severity alert. The affected asset, its owner and criticality tier, the sidebar evidence summary, and any repetition or same-flow correlation already live in the incident ticket. For sub-Critical leads or proactive-hunt leads, the analyst still records the affected asset and its criticality tier before executing the runbook.
A Hunt session open on the originating Data Exfiltration Detection Alert tab (for the primary trigger) or on a Netflows tab filtered to the upload-heavy flow (for the secondary trigger), with the detail sidebar visible.
Access to the organization's asset inventory for the affected host.
A working mental model of the organization's routine outbound upload traffic — which corporate Software-as-a-Service (SaaS) backup and file-sync destinations are in daily use, which cloud-storage buckets the organization owns or has sanctioned, which source-code hosts developers push to, which artifact repositories publish builds, and which business-partner endpoints exchange bulk data on a schedule.
Access to the incident-management system used by the SOC and to the organization's Data Loss Prevention (DLP) channel if one is in use.
Awareness of the organization's working hours and any sanctioned batch-upload windows (nightly backup, scheduled reporting exports) so the time-of-day reading in step 6 is calibrated against the local baseline.

Missing any of these is a hard stop. A data-exfiltration investigation run without asset context or without a clear picture of sanctioned upload destinations tends to either over-escalate legitimate cloud-backup traffic or under-escalate a genuine compromise — both failure modes are avoidable with the prerequisites in place.

Investigation Steps

Each step is numbered, adds a distinct piece of evidence, and feeds the decision tree at the end. The analyst executes steps in order even when the verdict looks obvious early; an exfiltration disposition is never safely recorded on partial evidence because the pattern can be a benign cloud backup and a malicious data theft at the same file-direction byte ratio.

On the Hunt page, the analyst clicks the alert row to open the detail sidebar. The sidebar header carries the alert type, the severity label, and the confidence score. The Data Exfiltration Detection section lists the pipeline's windowed aggregate:

flow_count — the total flows the pipeline counted in the 15-minute window for the (src_ip, dest_ip, dest_port, app_proto) group.
unique_flows — the count of distinct 5-tuple flows in the window; helps distinguish one long session from many short ones.
total_upload_bytes and total_download_bytes — raw byte sums across the window, client-to-server and server-to-client.
upload_mb and download_mb — the byte sums rendered in megabytes.
upload_ratio — total_upload_bytes / total_download_bytes, capped at 999.99 when the server sent zero bytes.
malicious_iocs and iocs_checked — the pipeline's independent IOC check against entities on the destination side.
dest_country, dest_asn, dest_org — GeoIP-derived destination characterization.
window_start and window_end — the 15-minute window bounds the aggregate was computed over.

The base network section above carries src_ip, src_port, dest_ip, dest_port, proto, app_proto, and the community_id correlator. The analyst captures the full base record so subsequent pivots have a reference point.

When the lead is a proactive-hunt lead rather than an alert, the equivalent fields live on the Netflows row (bytes_toserver, bytes_toclient, pkts_toserver, pkts_toclient, flow.duration, the flow-end reason) and on the sidebar's Flow section; the analyst captures those numbers and proceeds.

2. Examine the upload volume and upload ratio against the severity tier

Data Exfiltration Detection's severity mapping is mechanical: it keys off the ratio and the absolute upload volume, and any IOC match on the destination promotes the alert to Critical regardless of the behavioral numbers. The analyst reads the numbers from step 1 and locates the alert on the following ladder.

Severity	Upload Ratio	Upload volume	Notes
Critical	>= 10:1	>= 100 MB	Or any IOC match, any ratio, any volume.
High	>= 5:1 with >= 10 MB, or >= 2:1 with >= 100 MB	—	Two independent paths into this tier.
Medium	>= 2:1	>= 10 MB
Low	>= 2:1	>= 1 MB	Minimum threshold; many benign uploads land here.

A threshold-Critical Data Exfiltration alert on 200 MB uploaded at a 15:1 ratio is categorically a larger signal than a threshold-Low alert on 1.5 MB at a 2:1 ratio; the analyst's expectation for how much corroborating evidence is needed scales accordingly. The analyst also sanity-checks the reading against the underlying flow behavior: a single very-large flow versus many moderately-large flows carry different implications even at the same severity tier. Many flows suggest a sustained upload session (backup, chunked transfer); one large flow suggests a single-object upload (a compressed archive, a database dump).

The analyst records the ratio, the volume, the flow count, and the severity tier explicitly in the ticket. "45 flows totaling 212 MB uploaded against 8 MB downloaded (26.5:1 ratio) over a 15-minute window, severity Critical" is the kind of note that survives handoff.

3. Verify the source is internal and the destination crosses the network boundary

The pipeline already enforces the directional boundaries at construction — src_ip must be inside an RFC-1918 range and dest_ip must be outside all RFC-1918 ranges — so every surfaced alert meets these conditions. The analyst confirms them anyway because the same verification surfaces two kinds of misclassification that invalidate the rest of the investigation.

Incorrectly-classified internal ranges. Some organizations extend their internal network into carrier-grade Network Address Translation (NAT) space (100.64.0.0/10), link-local (169.254.0.0/16), or unique-local IPv6 (fc00::/7) ranges the pipeline does not treat as RFC-1918. When src_ip falls into one of those ranges, the flow is internal-to-external only by the pipeline's definition; the analyst verifies against the organization's network diagram before treating the destination as truly external.
Public IPs on internal infrastructure. Some enterprises route specific internal services through public IP ranges the organization owns. When the destination dest_ip belongs to an owned public range, the alert is internal-to-internal in practice and the exfiltration hypothesis does not apply. The analyst identifies owned ranges from the asset inventory or from the organization's IP address management record.

When both sides check out — source is a genuine internal host, destination is genuinely outside the organization's network — the analyst notes the source's subnet and role (workstation subnet, server subnet, operational-technology subnet, guest Wi-Fi subnet) and the destination's reachability path (direct outbound, through an enterprise proxy, through a monitored egress point). This context governs how the later vendor-identification step reads the destination.

4. Characterize the destination endpoint

The destination is the prospective exfiltration endpoint. The analyst characterizes it along three dimensions before pivoting any further, using dest_country, dest_asn, dest_org, and the reverse-DNS name when available.

Known corporate cloud storage. The destination resolves to a mainstream cloud-storage or object-store provider the organization has sanctioned — Amazon Simple Storage Service (S3), Azure Blob Storage, Google Cloud Storage, Backblaze B2, Wasabi, DigitalOcean Spaces. The ASN and reverse DNS usually identify the provider; when the sanctioned bucket identity can be confirmed (from the TLS Server Name Indication (SNI), the Hypertext Transfer Protocol (HTTP) hostname, or the hostname label visible in the DNS record that preceded the flow) the hypothesis leans strongly toward sanctioned backup / file-sync.
Recognized business SaaS or partner endpoint. The destination resolves to a known Software-as-a-Service (SaaS) provider the organization uses (corporate OneDrive, Google Workspace, Dropbox Business, Box, Salesforce, a specific managed-file-transfer platform) or to a business-partner endpoint on an approved data exchange. The hypothesis is similar to sanctioned cloud storage, but the verification checklist shifts to confirming the user account, the sanctioned workflow, and the client identity.
Unknown third-party endpoint. The destination resolves to a hosting provider, a virtual-private-server reseller, a residential or small-business Internet service provider, a bulletproof host, or a paste / public-file-sharing service the organization has not sanctioned for outbound data. The reverse DNS may be generic (numbered customer subdomains) or absent. The dest_org reads as a reseller rather than a first-party cloud provider. This category carries the heaviest suspicion on its own and pairs with the protocol reading in step 5 to resolve the hypothesis.

The analyst records the destination characterization explicitly. "dest_ip 52.216.72.10, ASN 16509 Amazon.com, reverse DNS s3-1.amazonaws.com, matched TLS SNI company-backups-prod.s3.amazonaws.com — known corporate S3 bucket" is one shape; "dest_ip 185.x.x.x, ASN 200325 XYZ-Reseller, country RO, no reverse DNS, SNI missing — unknown third-party hosting" is the other.

5. Check the protocol and the session evidence

The protocol and the session payload either corroborate the destination characterization from step 4 or contradict it. The analyst reads proto and app_proto from the base section and then pivots to the session tab for the same flow.

From the alert sidebar the analyst right-clicks community_id and selects Show all events with this community id. A new All Events tab opens on the Hunt Page filtered to every protocol transaction, flow record, file extraction, and enrichment that belongs to the same connection. This view exposes:

The declared application protocol. Transmission Control Protocol (TCP) port 443 with app_proto: https or tls is the expected shape for cloud-storage and SaaS uploads. TCP port 80 with plaintext HTTP for a multi-megabyte upload is atypical outside legacy integrations. Secure Shell (SSH) / Secure File Transfer Protocol (SFTP) on port 22, File Transfer Protocol (FTP) on ports 20–21, Server Message Block (SMB) on port 445, or raw TCP with app_proto: null or failed on an unusual port is disproportionately associated with off-channel data movement.
The TLS session, when the upload is encrypted. The Server Name Indication (SNI), the certificate subject and issuer, and the JA3 / JA4 client fingerprint identify the client and the endpoint even when the payload is opaque. A recognizable enterprise-backup-client JA3, a corporate-cloud SNI, or a valid certificate issued to the organization's cloud tenancy all corroborate the sanctioned hypothesis. An unfamiliar JA3, a self-signed or Let's-Encrypt-issued certificate for a reseller hostname, or an SNI that does not resolve back to the destination IP under normal DNS all corroborate the suspicion hypothesis.
The HTTP session, when the upload rides plaintext HTTP. The method is expected to be PUT or POST; the User-Agent identifies the client software; the URL path and the Content-Type hint at what is being uploaded (application/json, application/octet-stream, application/zip, multipart/form-data). Recognizable backup-agent or cloud-client user agents identify sanctioned tooling; generic curl, Wget, python-requests, or the default User-Agent for a scripting language raise suspicion, especially from a non-developer workstation.
The DNS resolution that preceded the flow. When the destination was reached by name, the DNS query and answer sit on the same community_id. The resolved name either confirms the destination characterization (it matches a corporate cloud hostname) or contradicts it (the hostname is a random-looking label under a generic top-level domain).

The session evidence usually resolves the ambiguity between sanctioned corporate cloud and unknown third-party endpoint. When the protocol is opaque (raw TLS without a usable SNI) and no session evidence is available, the hypothesis stays open and the blast-radius and PCAP steps add independent weight.

6. Examine the time-of-day pattern

Exfiltration is a timing signal in addition to a volume signal. The analyst reads the window_start timestamp against the organization's working hours and the source host's baseline pattern.

Business-hours upload from a workstation consistent with the user's role. A developer workstation pushing a 150 MB build artifact to a sanctioned artifact repository at 14:00 local time is weak evidence of exfiltration even at a 15:1 ratio. The volume and the timing match the workflow.
Off-hours upload from a workstation whose user is not working. The same workstation uploading 150 MB at 02:30 local time with no scheduled backup window is a strong evidence-weighting shift toward exfiltration. The analyst verifies against any sanctioned overnight-backup schedule and against the organization's endpoint activity logs (if available from the EDR) to rule out a legitimate scheduled job.
Uploads from a server during a declared backup window. Database servers and file servers often have nightly or weekly backup windows that produce large, ratio-lopsided uploads to a sanctioned cloud destination. The timing corroborates the sanctioned hypothesis when the window matches; it contradicts it when the upload falls outside the scheduled window.
Recurring uploads at the same time every day from the same source to the same destination. The pattern matches a scheduled integration (automated reporting export, log shipping, monitoring agent). Sanctioned integrations are discoverable against the organization's integration catalog; unknown recurrences are leads in their own right.

The analyst records the timing reading in the ticket alongside the local working-hours context. "Window 02:17–02:32 local, off-hours for this workstation's user, no sanctioned backup schedule registered for this host" is the kind of note the disposition rests on.

7. Check for IOC enrichment on the destination

This is the single strongest disposition lever in the runbook. The alert sidebar carries the C2 Enrichment section whenever any C2 feed match fired on the destination; the Insights Enrichment section carries parallel matches from the OPSWAT InSights Threat Intelligence Database (TIDB) and Reputation Database (REPDB) feeds.

Any c2.matches[] entry present. The alert is IOC-Critical by construction. Severity is Critical, alert-level confidence is 0.99, and the match payload identifies the threat actor or malware family the indicator belongs to. This finding on its own is sufficient for escalation to incident response (see Decision Tree).
Data Exfiltration pipeline malicious_iocs > 0 with iocs_checked > 0. The behavioral pipeline's independent IOC check observed a feed hit on the destination during the window. The pipeline auto-escalates its own severity to Critical when this field is truthy. Confidence on the alert rises to 0.99 under the same auto-escalation rule.
Parallel InSights match on the destination IP or DNS name. See InSights TIDB and REPDB for the feed semantics. A TIDB hit (threat intelligence) is high-confidence; a REPDB hit (reputation) is lower-confidence but still material in aggregate, and a REPDB hit on a paste / anonymous-file-sharing category corroborates an exfiltration hypothesis even without an actor-linked TIDB entry.
No IOC match on any feed. The alert is threshold-Critical (or sub-Critical) on behavioral evidence alone. The case for escalation now depends on the volume and ratio in step 2, the destination characterization in step 4, the protocol and session evidence in step 5, the timing evidence in step 6, and the blast-radius evidence in the next step.

The analyst records the IOC state explicitly in the ticket — "IOC match present on dest_ip / dns query name / neither" — because it is the single field that changes downstream dispositions.

8. Check the blast radius and request a PCAP when session evidence is insufficient

A destination that only one internal host uploads to is a host-scoped event; a destination that many internal hosts upload to is an environment-scoped event that is either a coordinated compromise or a benign shared service. Blast radius is a decisive piece of evidence.

From the alert row the analyst right-clicks the destination IP (or the destination domain for a DNS-match alert) and selects Hunt all events from this IP (or runs a quick search on the domain in a new All Events tab). The time range expands to Last 24 hours or Last 7 days as appropriate. The analyst reads the result:

One source only. The event is host-scoped. Escalation, containment, and forensic recovery target the affected host.
A small handful of sources, all sharing a common software baseline (same EDR agent, same backup agent, same build image). The shared behavior points at a sanctioned workflow when the destination is a recognized vendor, or at a coordinated compromise when the destination is unknown. Blast radius is redrawn to include the whole set either way.
Many sources across business units to a recognized cloud / SaaS provider. The destination is almost certainly a sanctioned endpoint and the alert volume is a tuning candidate rather than an incident. The analyst still confirms the client identity on at least one sampled connection before closing.
Many sources across business units to an unrecognized third-party endpoint. This is the strongest population-scale exfiltration signal. The investigation escalates immediately to incident response regardless of the behavioral severity tier.

The analyst then opens a second tab using the right-click pivot Hunt all events from this IP on the source IP and widens the time range to Last 7 days. This tab shows every conversation the affected host has held with any external destination. A host uploading to one suspicious destination is a host-scoped compromise; a host that has been uploading to a drifting set of suspicious destinations over days is a longer-horizon problem that changes the escalation shape.

When the session evidence from step 5 is insufficient — the upload rode a raw TLS connection with no SNI, the session is a custom TCP stream with no application-protocol parse — the analyst requests a PCAP for the flow's time window through the organization's PCAP request workflow. PCAP availability is configuration-dependent and selective on MetaDefender NDR (see Alert, Flow, and PCAP Pivoting), so not every flow has a retained PCAP; when one is available, the analyst inspects file-type magic bytes at the start of the upload, Content-Type headers for any inner protocol the capture exposes, and the overall byte cadence to judge whether a single large object or a chunked session produced the volume. When a PCAP is unavailable, the investigation concludes on the evidence already gathered; the analyst explicitly records the gap in the ticket so a disposition on partial evidence is traceable.

Decision Tree

The analyst records one of four outcomes. Each branch lists the minimum artifacts captured before the ticket is closed.

Escalate — confirmed or probable exfiltration. The disposition when any of the following holds: the alert is IOC-Critical (any c2.matches[] entry or malicious_iocs > 0) on any source; the alert is threshold-Critical (ratio >= 10:1 with upload >= 100 MB) to an unrecognized third-party destination on a Tier 1 or Tier 2 asset; two or more independent indicators converge (an unrecognized destination, off-hours timing, a client User-Agent or JA3 inconsistent with sanctioned tooling, a paste-site or file-sharing REPDB hit, a PCAP showing archive-file magic bytes); or the blast-radius pivot surfaces the same unrecognized destination across multiple business units. The analyst opens an incident response (IR) ticket, requests endpoint isolation for the affected host (or hosts), hands the source off to forensic recovery, blocks the destination at the perimeter when the organization's policy allows indicator-based blocking, engages the organization's Data Loss Prevention (DLP) channel, and transfers the evidence record and pivot tabs into the incident. The Escalate branch is where this runbook ends and incident-response procedures take over.
Monitor — suspicious but not conclusive. The disposition when the evidence is partial: a Medium or High Data Exfiltration alert to a destination that is a known cloud provider but where the sanctioned bucket identity cannot be positively confirmed; an off-hours upload that matches a previously-declared backup schedule but has no ticket trail; a Tier 3 asset producing a one-off ratio-heavy flow with no corroborating signals. The analyst records the observation in the ticket, leaves the Hunt tabs open, schedules a follow-up review (typically within four to twelve hours for Critical severity and twenty-four hours for sub-Critical), and watches for re-occurrence or new corroboration. When the pattern recurs within the review window, the analyst re-enters at step 1 with the accumulated context and re-evaluates; when it does not recur and no new evidence surfaces, the disposition moves to close as benign.
Close as benign — identified legitimate explanation. The disposition when the evidence positively identifies a sanctioned upload pattern: the destination is a confirmed corporate S3 bucket or Azure container with a matching SNI, the client identity (User-Agent, JA3 fingerprint) matches a sanctioned backup agent, the timing matches a declared backup window, and the source host is expected to participate in that workflow. The analyst records the specific fields that justify the conclusion in the ticket — "destination company-backups-prod.s3.amazonaws.com, ASN 16509, JA3 fingerprint 771,49195-... matches corporate Veeam backup agent, window 02:00–04:00 aligns with nightly backup schedule for subnet 10.10.8.0/24, closing as benign" is the shape of a defensible close-note — so later readers can reopen the conclusion when one of those fields changes.
Tune the rule — recurring benign pattern with a scoped policy fix. The disposition when the same sanctioned upload pattern has been confirmed multiple times across the same population, the source of the noise is understood (a specific backup product, a specific artifact repository, a specific reporting integration), and the policy system supports a scoped exclusion. The correct tuning for Data Exfiltration is the scoped allowlist described in Behavioral Detections: adding the specific destination (for example, the corporate S3 endpoint for an approved backup workflow) to the Policy's exfiltration allowlist rather than raising the minimum-upload floor globally. Tuning is a detection-engineering action, not a triage shortcut: the analyst opens a follow-up task against the detection's policy definition rather than tuning inline, submits the change through the organization's peer-review workflow, and keeps the alert live until the tuned policy deploys. The default disposition for a single confirmed-benign alert is close, not tune — a single occurrence does not justify reducing coverage.

Every branch is recorded in the incident-management system. The runbook reference, the disposition, the asset context, the ratio / volume / timing / IOC evidence, and the pivot tab references form the minimum record. When the disposition is Escalate, the record hands off directly into the incident.

Common False-Positive Patterns

A material share of Data Exfiltration alerts have benign explanations. Recognizing the patterns saves investigation time and keeps analysts from over-escalating.

Sanctioned cloud backup and file-sync uploads. Corporate OneDrive, Dropbox Business, Google Workspace Drive, Box, iCloud, and enterprise Veeam / Commvault / Rubrik / Acronis backup agents produce large, ratio-lopsided uploads to the vendor's cloud on a schedule. The destination ASN and SNI usually identify the vendor; the client User-Agent or JA3 usually identifies the agent. Disposition: close with the vendor identity and the sanctioned workflow recorded. When the same vendor produces sustained alert volume across many hosts, the SOC opens a tuning task against the Data Exfiltration policy to add the destination to the allowlist.
Source-code push and artifact-repository uploads. Developer workstations pushing branches to GitHub, GitLab, Bitbucket, Azure DevOps, or an internal Git server produce ratio-heavy uploads during working hours. Continuous-integration (CI) runners push build artifacts to Amazon Elastic Container Registry, Google Artifact Registry, Nexus, Artifactory, or similar. The source identity (developer workstation, CI runner) and the destination identity (known code or artifact host) resolve this pattern quickly. Disposition: close with the sanctioned workflow recorded.
Business-integration batch exports. Scheduled data transfers between the organization and approved partners — nightly financial reporting, data-warehouse extracts to a shared staging bucket, compliance exports to a regulator's endpoint — produce recurring ratio-heavy uploads at the same time every day. Disposition: close with the integration identity recorded; when the same integration generates recurring alerts, the SOC opens a tuning task to add the destination to the allowlist.
Video-conferencing and real-time-communication uploads. Extended Zoom, Microsoft Teams, Google Meet, or Webex sessions from a conference-room host or a busy user can produce surprisingly ratio-heavy flows because the client uploads camera and screen-share streams while receiving mostly control traffic during active speaking. The destination is usually a known media relay and the SNI identifies the vendor. Disposition: close when the destination and client are recognized.
Telemetry and observability data export. Application-performance-monitoring agents, log-shipping collectors, metrics forwarders, and endpoint-detection-and-response (EDR) cloud uploaders produce many small, ratio-heavy flows to the vendor's ingestion endpoint. The vendor identity is usually recognizable from the SNI. Disposition: close when the vendor is identified; tune via policy only when the same vendor produces sustained alert volume.
Misclassified internal destinations. An internal file server, internal backup target, or internal artifact repository that is reachable over a public IP — or an internal subnet not in the standard RFC-1918 ranges the pipeline enforces — can surface as an exfiltration alert. Disposition: close once the destination identity is confirmed; a follow-up task is opened against the sensor home-net configuration or the pipeline's RFC-1918 definition when the misclassification is systemic.
Red-team, penetration-testing, and attack-simulation activity. Authorized internal testing produces exfiltration alerts by design; exfiltration-simulation frameworks upload large archives to attacker-controlled cloud endpoints as part of the evaluation. Disposition: close once the activity is confirmed with the red-team or vulnerability-management program. Every SOC maintains a communication channel with internal testing teams so these alerts are identifiable on sight.

Closing on a false-positive pattern still requires the runbook's evidence record. "Looks like a backup" is not a disposition; "destination company-backups-prod.s3.amazonaws.com, ASN 16509, JA3 matches corporate Veeam agent, timing aligns with scheduled 02:00 backup window" is.