Detecting T1052 Exfiltration over physical medium

How T1052 exfiltration over physical medium moves data out of a network

A SOC lead needs a direct answer: can removable media carry sensitive data out of a monitored environment without touching the network? Yes. T1052, Exfiltration over physical medium, describes an adversary moving stolen data out on a physical device such as a USB drive, external disk or other portable storage, so the data never crosses a network path the monitoring stack can see. The technique sits under the Exfiltration tactic (TA0010), which MITRE ATT&CK defines as: "The adversary is trying to steal data." This page targets ATT&CK Enterprise version 20.0, and every detection mapping below should be read against that version because technique names, sub-techniques and mappings can change between releases. According to the supplied ATT&CK data, T1052 has one sub-technique. Its use appears in two kinds of cases: intrusions where an adversary with local access copies data to removable storage to avoid network egress controls, and insider cases where an authorized user does the same deliberately or carelessly. From a defender's point of view, the two look alike in the endpoint record, so the detection design must not depend on knowing the actor's intent. Confirm with your own threat intelligence team which of these patterns has appeared in your sector and which removable media paths are in use across your fleet.

The practical decision for the SOC lead is where removable media is allowed and what evidence is kept when it is used. Start by inventorying which endpoint classes permit mass storage, which ones are in scope for regulated data, and whose telemetry records device mount and file copy events. Those answers determine whether the detection will rely on endpoint file access and process records, on device control policy, or on both. Ask your endpoint and Data Loss Prevention vendors to state in writing which device and file events they log, how long those logs are retained, and whether removable media writes can be blocked, audited or allowed by policy. The data component and mitigation mappings in the ATT&CK data for this technique are covered in the sections that follow. The point to plan for now is that a network-only monitoring design will not see this technique at all. Confirm the telemetry on each platform you run, including Linux, macOS and Windows hosts, before you accept any claim that removable media exfiltration is covered.

Which telemetry reveals removable media exfiltration and which open-source tool collects it

This table maps the ATT&CK data components Process Creation, File Access and Command Execution to the signal each one gives for T1052 activity on removable storage, and names the open-source collector to use. Read each row as a source to enable, then confirm per operating system which fields your agents actually capture before relying on it. The main takeaway is that no single source covers removable media use end to end, so pair host telemetry with mount events and file-level context.

Data component	Signal for removable media exfiltration	Collector and what to confirm
Process Creation (DC0032)	A copy, archive or sync process started with a target path on a newly mounted removable volume, such as a drive letter or mount point not seen before on the host.	Wazuh agent with Sysmon on Windows, auditd on Linux and macOS process logging. Confirm command-line capture is enabled, since process names alone rarely show the destination.
File Access (DC0055)	Reads of sensitive directories followed shortly by writes to a removable volume, or bulk file writes to a new mount point on the same host.	Wazuh file integrity and auditd watch rules for sensitive paths on Linux, Sysmon file create events on Windows. Confirm which paths are watched, since unwatched directories produce no signal.
Command Execution (DC0064)	Shell or script activity that mounts a device, lists removable volumes or copies data to removable storage, captured as command lines or script block content.	Wazuh agent log collection of shell history and PowerShell logging where enabled, with Velociraptor for hunting command history across endpoints. Confirm logging policy, because shell history is often disabled or truncated.
Mount and device events (host context)	Insertion of a USB or other removable device, with device identifiers and the user session active at the time of mounting.	Sysmon device and volume events on Windows, udev and mount logs on Linux collected by Wazuh. Confirm that device-level events are retained long enough to correlate with later file activity.
Host context and correlation	Timeline of process, file and mount events on one host, used to confirm whether a copy to removable media followed a sensitive read.	Security Onion for pulling host alerts together with network and endpoint context. Confirm which endpoint sources feed it in your deployment, since Security Onion does not collect removable media events on its own.
Coverage by operating system	Windows usually offers the richest built-in process and device logging, Linux depends on auditd rule design, and macOS coverage varies with unified logging configuration.	Test each platform in the cyber range before treating it as covered. Confirm with the collector documentation which events each operating system emits in your version.

Detection logic for T1052 that SOC teams can tune

The four ideas below share one question: did data move from a sensitive location onto removable media in a way a normal user would not? Each card states the logic, the thresholds to tune for your environment, and the benign activity that will trigger it. Map each rule to the ATT&CK v18 detection strategy and analytic for T1052 in the version you target, since detection strategy IDs and analytics changed in that release.

Bulk reads before media writes

This rule correlates File Access events on sensitive directories with a later write to a removable volume by the same process or user within a short window. The logic is a sequence: a high count of reads across a protected share, followed by a write to a removable drive. Tune the read count, the sensitive path list and the window to match how your file servers and endpoints behave. False positives come from backup agents, sync clients and eDiscovery exports that read widely and write to attached drives. Exclude them by signed binary and service account, not by user name alone.

Large copy after device attach

A removable storage device attach event followed by sustained copy activity from the same host is a strong signal when the copy volume exceeds the normal baseline for that user group. Use Process Creation and file write telemetry together, and set the volume threshold per role rather than globally. The key check is whether the device was approved and whether the transfer reached a path outside the expected working set. Approved encrypted drives, enterprise imaging tools and software installers that stage files on USB media will also trip this logic, so maintain an allowlist of device serials and installer hashes.

Archive creation before media writes

Creating a compressed or encrypted archive in a temporary or user profile directory, then writing that archive to removable media within minutes, is a common staging pattern. The rule combines Process Creation for archive utilities with a file write to a removable volume. Tune the time window, the archive extensions you monitor and whether the host is a developer or build system where archiving is routine. Legitimate sources include build pipelines, log rotation and user backup scripts. Review these by parent process and scheduled task name before escalating.

Media use by non-admin accounts

Removable media use by standard user accounts on hosts where those accounts have no business need is a baseline deviation worth reviewing. Build the rule from device attach events joined to user group membership, and alert only when the account is outside the groups approved for removable media. The threshold is a frequency and role comparison, not a single event. Expect noise from help desk staff, field engineers and kiosk or lab machines, so tag those hosts and roles in your asset inventory before you enable the rule in blocking mode.

How to validate the T1052 detection in a lab before trusting it

This sequence proves that a T1052 detection fires on a planned, authorized emulation of removable-media exfiltration, and it leaves a dated record that shows which telemetry, rules and alerts were involved. Teams use the result to decide whether the detection is ready for production and whether it still holds after changes.

Agree scope and rules of engagement
The security lead, the owner of the test hosts and the detection engineer agree in writing which hosts, accounts and removable-media controls are in scope, who may run the emulation, when it may run and how it stops if something unexpected happens. The lab or cyber range owner confirms that the test estate is isolated from production data and that a rollback path exists. The step is done when every party has signed off on the document and the stop conditions are written down.
Define the simulated data set
Define a synthetic data set that looks like the sensitive content the organization cares about, such as labeled dummy records with tagged file names and markers that never touch real customer or employee data. The detection engineer records the file types, sizes, folder locations and the expected classification for each item, so later analysis can match each event to a known object. The step is complete when the data set inventory and its expected detection outcomes are stored with the test plan.
Confirm baseline telemetry and rule state
Before the run, the engineer checks that the Linux, macOS and Windows test hosts forward process creation, file access and command execution events to the monitoring platform, and that the Wazuh or Sigma rules under test are enabled at the versions expected. The engineer captures the rule identifiers, versions, data component coverage and the ATT&CK version the rules map to, such as v20 if the mappings target that release. The step is done when a baseline snapshot is saved and any gaps in log sources are logged as known limitations.
Run the emulation at a defined pace
An operator, separate from the person who wrote the rules, runs the agreed emulation steps at a fixed pace that is written in the test plan, with the observer present or watching the console. Pace matters because bursts and slow copies can trigger different thresholds, so the plan should cover both. The step is done when the operator confirms that every planned action has been executed or formally marked as skipped, with the actual start and end times recorded.
Record which telemetry fired and when
The observer exports the raw events and alerts for the test window and records, for each action, the timestamp, host name, user account, device identifier such as the removable drive serial or mount label, and the alert ID generated by the rule. Missing events are noted with the log source that should have produced them. The step closes when the evidence bundle is saved under the test record with the time zone stated, so every entry can be traced back to the planned action.
Compare results against expected alerts
The detection engineer compares the planned actions with the recorded events and alerts, sorting each outcome into fired as expected, fired late, fired with the wrong severity, not fired, or fired on benign activity. Each gap gets a root cause, such as a missing data component, a field that is not normalized or a threshold that is too high. The step is complete when a signed results table lists every planned action with its outcome and the agreed actions to fix the gaps.
Re-test after rule or ATT&CK changes
Each time a rule is changed, a data source is added or ATT&CK is updated to a new release, the engineer repeats the relevant part of the emulation and compares the results with the previous baseline. The ATT&CK release notes should be checked for renamed, deprecated or revoked techniques that affect the mapping. The step is done when the regression results are recorded against the new rule version and the ATT&CK version the detection targets, and the detection owner approves its status.

Mitigations that reduce removable media exfiltration

T1052 depends on a person or process moving data onto a physical device that leaves the organization's control. The two ATT&CK mitigations for this technique, Data Loss Prevention (M1057) and Disable or Remove Feature or Program (M1042), work at different points: one inspects and blocks what is written to removable media, the other removes the ability to use the device at all. The cards below separate what each control decides, where it fails, and what to confirm in the product documentation before relying on it.

Block unneeded removable media

Disable or Remove Feature or Program (M1042) is the most direct limit on T1052 because it removes the device path itself. For endpoints that do not need USB mass storage, the mounting of that device class can be turned off through the operating system or endpoint management policy. Scope the change by role and device class rather than by blanket disablement, so that approved workflows still function. What it cannot stop is data copied through a channel that remains open, such as a cloud sync client or a personal phone connected for charging. Confirm in your endpoint platform documentation which device classes it can restrict and whether it can log blocked attempts.

Content-aware removable media policy

Data Loss Prevention (M1057) applies when removable media must stay available but writes to it need to be governed. Content-aware rules classify files by sensitivity label, pattern or fingerprint and then allow, block, encrypt or log the copy. The main risk is over-tuning: rules that match only exact file names are easy to avoid by renaming, and rules that match everything create exceptions that users learn to route around. Test rules against representative sample files before enforcement. Confirm whether the chosen product inspects archives and whether it can inspect files already written to a device, since a copy made before the policy existed is a common gap.

Enforce encryption on approved media

Where removable media is allowed, requiring hardware or software encryption on the device limits the exposure if a drive is lost or copied outside a monitored endpoint. Encryption does not stop a user from copying data onto an encrypted drive that they are authorized to use, so it is a containment control, not a prevention control for T1052. Ask whether the platform enforces encryption before a device is writable, how keys are recovered when staff leave, and whether unencrypted devices are blocked or only reported.

Allowlist approved devices

Device allowlisting limits writes to specific, registered hardware identified by serial number or vendor and product identifiers. It shifts the question from whether a device should be blocked to which devices the organization has decided to trust. Identifiers can be spoofed, and an allowlist that is never reviewed becomes a list of every device ever plugged in. Assign ownership for adding and removing entries, and confirm in the product documentation whether allowlists can be bound to a user, a group or a host, and how exceptions are approved and logged.

Log every removable media event

Prevention controls are only as useful as the record they leave behind. Each device connection, mount, blocked write and allowed copy should be sent to the central log platform with the user, host and device identifier, so that Wazuh, Security Onion or another SIEM can correlate them with file access and process creation events. A control that blocks silently makes it hard to tell an attack from a broken workflow. Confirm the event fields the endpoint agent emits, the retention period on the endpoint and in the SIEM, and whether blocked events are sent in near real time.

Gaps these controls leave open

Neither M1057 nor M1042 stops an insider who photographs a screen, prints a document or dictates content to a personal device. Removable media controls also do not cover data moved through a cloud client, a shared network folder or an email attachment, which are handled by other techniques in this pillar. Treat these controls as one layer. Ask any implementation partner or platform vendor to document which exfiltration paths the chosen configuration covers and which it does not, and record that in the risk register.

What the SOC does in the first hour after a removable media alert

The first hour after a removable media alert for T1052 Exfiltration over physical medium is about establishing facts before anyone touches the device or the user. The analyst should first confirm which device triggered the alert, using the device identifier, serial number and the host it was attached to, and then establish who owns the endpoint and who was logged in at the time. Next, preserve the evidence before any cleanup: export the relevant host and device logs for the attachment window, including process creation, file access and the mount or device-connection events the endpoint recorded, and store them in the case system with timestamps and a chain of custody note. Confirm with the endpoint owner and the asset inventory whether the device is company-issued, personally owned or unknown, because that answer changes every later decision.

Once the device and logs are secured, the team needs to know what left the endpoint. Work with the data owner or classification register to identify the files involved and their sensitivity level, since a copy of a public document and a copy of customer records require very different responses. Ask the user, through the designated investigator rather than the analyst alone, whether there was a documented business reason such as an approved transfer to a vendor or an offline workflow. Containment is a decision, not a reflex: the options include blocking the device at the endpoint or device-control layer, isolating the host from the network, or doing nothing beyond monitoring while facts are gathered. Document the reason for whichever option is chosen. Where the facts point to personal data, regulated records or a possible insider act, bring in HR, legal and the relevant data owners early, and confirm your organization's escalation matrix and notification obligations with them rather than assuming the timeline.

Rehearsing T1052 detection and response in a private cyber range

On Linux and macOS endpoints in the range, the rehearsal should mount a removable device and write a labeled test dataset to it under an authorized account, then observe what the endpoint agent records. The range topology for these hosts includes a small set of endpoints enrolled in a monitored SIEM, a simulated data store that represents a sensitive share, and a removable device that the test team controls. The inject is a planned write of canary files whose names and hashes are known in advance, so detections can be matched to a specific action.

Process and mount telemetry: Confirm that process creation and mount events for removable storage reach the SIEM, and that the event carries the user, host and device identifiers.
File access coverage: Check that reads from the simulated data store are logged with the path and process name, since file access is the data component that links the source to the copy.
Alert timing: Record the time between the inject and the first alert, and set a target agreed with the SOC before the exercise starts.
Context and severity: Verify that the alert names the device, the account and the canary files, and that its severity matches the agreed policy for sensitive data.
Logging gaps: Note any macOS or Linux distribution where the agent does not capture the mount or write event, and record the agent version for follow-up.

Before the exercise, ask your provider to confirm which telemetry each agent version emits in your environment.

Questions SOC leads and detection engineers ask about T1052

How do I separate approved encrypted drives from exfiltration over a physical medium?

Approved encrypted drives are separated from T1052 activity by building an allow model around device identity, not around the file type. Start by inventorying which removable media models and serial numbers your organization issues, then compare each USB storage connection event against that list. Alert on unregistered devices, on approved devices used outside expected hosts or hours, and on large volumes of copied files from sensitive shares to removable media. Encryption alone is not a control signal, because an adversary can use an encrypted drive too. Confirm with your endpoint vendor which removable media events and device identifiers your agent records on each operating system, since coverage differs by platform and version.

What should we do about removable media activity on devices with no monitoring agent?

Devices without an agent are a blind spot, so treat them as a coverage gap to close rather than a case you can monitor around. Inventory them first using your asset source of truth and network discovery, then decide per device class whether to install an agent, restrict USB storage through platform policy, or isolate the device from sensitive data. Where an agent cannot be installed, use the controls your operating system and management tooling already provide, such as device control policy, and record the residual risk in your risk register. Ask any implementation partner to document which device classes are excluded and why.

How often should we re-validate T1052 detection rules after an ATT&CK version change?

Re-validate after every ATT&CK version you adopt, and check the release notes for changes that touch T1052 or its mitigations. MITRE publishes updates on a regular cadence, and recent releases include v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026. Releases can rename, deprecate or revoke techniques and move detections into new detection strategies and analytics, so each rule should record the ATT&CK version it targets. Keep a standing review step in your change process and rerun your validation tests whenever the mapping or your data sources change.

How do we measure detection coverage for T1052 in a way an auditor can follow?

Measure coverage by mapping each detection to the T1052 technique, its data components and the endpoint platforms it applies to, then recording the result of a validation test for each. Useful measures are the share of in-scope endpoints that report removable media events, the share of rules that have passed a test in a cyber range within the last review cycle, and the number of known gaps with an owner and a date. Use the ATT&CK STIX data for your target version as the reference for mappings, and keep the evidence in version control. Note that these measures show coverage of your own telemetry, not the absence of activity.

What telemetry do we lose when endpoints are offline, and how do we recover it?

When an endpoint is offline, you lose real-time process creation, file access and removable media events from that host until it reconnects. Events that the agent buffers locally may arrive later, but events that expire or are not buffered are gone. Confirm your agent's buffering behavior and retention limits with the vendor. To recover what you can, collect local logs after reconnection, review file system artifacts with a forensic collection tool such as Velociraptor, and check whether file servers or data loss prevention tools logged the transfers from the other side. Flag offline periods in your monitoring so analysts know which time windows are incomplete.

Which mitigations reduce T1052 risk most, and how do we prove they work?

The ATT&CK mitigations mapped to T1052 are Data Loss Prevention and Disable or Remove Feature or Program. Data loss prevention can restrict which files may be written to removable media and log attempts, while disabling or removing unneeded removable storage support reduces the attack surface on endpoints that do not need it. To prove they work, test each control in a private cyber range with a scripted scenario that copies sensitive test data to a removable device, then confirm the block or alert and the log entry. Record the result, the control version and the date so the evidence can be repeated after changes.

Can our own team run T1052 detection validation, or do we need an outside partner?

Your team can run T1052 validation if it has someone who understands your endpoint telemetry, your detection platform and your test environment. The work includes building test cases in an isolated lab, running them against each rule, reviewing the logs and tracking results over time. Teams that lack capacity often engage a partner on a fixed scope, where the scope, deliverables and timeline are agreed in writing before work starts. Ask any provider to name the platforms, rules and ATT&CK version covered, and to hand over the test scripts and results so your team can repeat the work.

How DeployOpen builds T1052 detections and range exercises

DeployOpen approaches T1052 Exfiltration over physical medium as a fixed-scope engagement inside your own infrastructure, starting from the ATT&CK version your team targets. The work covers detection logic, validation in a private cyber range, and documentation your security and compliance teams can review.

How we scope

Confirm the ATT&CK version and platforms (Linux, macOS, Windows) that the written scope will target for T1052.
List the telemetry sources available today, such as Process Creation, File Access and Command Execution, and note any gaps.
Agree in writing which removable media controls and Data Loss Prevention policies are in scope, and which are excluded.

How we build

Write detection logic for T1052 in open-source formats such as Sigma rules, mapped to your Wazuh or Security Onion pipeline.
Map detections to the ATT&CK mitigations Data Loss Prevention and Disable or Remove Feature or Program, and document any configuration changes.
Test detections against benign and simulated activity in a private cyber range before anything reaches production.

How we hand over

Deliver rule files, configuration notes, and validation results with the ATT&CK version and data component references recorded.
Document the response steps analysts follow when a T1052 detection fires, including evidence to preserve and escalation paths.
Run a knowledge transfer session so your operations team can maintain and tune the detections after handover.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, agreed in a separate written scope.
Revalidate T1052 detections when ATT&CK releases change technique or mitigation mappings, and record each change.
Ask for a quote based on the written scope, since DeployOpen does not publish a price list.

T1052 Exfiltration over physical medium