How T1025 data from removable media shows up in intrusions
If your SOC needs to know when data leaves through USB or other removable drives, the signal is a sensitive file being read from a system and then written to a drive that the organization did not expect to receive it. T1025 Data from Removable Media covers the adversary step where data already collected on a device is copied off the removable media that a person or process attached. Within the Collection tactic (TA0009), ATT&CK defines the goal as gathering data of interest to the adversary's objective. Here, the removable drive is the medium through which that data is collected, so the technique is often seen just before or alongside staging and exfiltration activity, depending on how the intrusion unfolds. This page targets MITRE ATT&CK Enterprise version 20.0, which MITRE released on 2026-10-13 according to the attack-stix-data repository index.
In intrusions, the technique usually appears as an ordinary-looking file operation on a workstation or server that is followed by a drive being mounted and files being written to it. The SOC lead should confirm which hosts in the environment are permitted to use removable media at all, which roles need that access, and whether the endpoint platform records drive creation and file access events for those hosts. Those three checks decide whether a detection is feasible on each operating system. Mapping also needs discipline: ATT&CK can rename, deprecate or revoke techniques between releases, and detection logic written against one version may not match the next. Every detection rule, dashboard and coverage report should therefore name the ATT&CK version it targets, and the team should recheck the technique page at each update, starting with the ATT&CK updates page that MITRE publishes for each release.
The practical decision for the SOC lead is where to accept risk. Some organizations block removable storage outright, while others allow it for named roles and log every use. Each choice changes what the team must monitor and what counts as an alert. Whichever path is chosen, the alert should be tied to a documented business justification, so analysts can distinguish an approved backup from a copy of customer records heading out of the building. Agree that rule with data owners and HR before the first incident, not during it.
Which telemetry reveals removable media collection
This table maps each telemetry source to the signal it can show during T1025 activity and the open-source collector that gathers it. Read each row as a question to answer in your own environment: can this collector see this signal on this platform? Rows marked for confirmation depend on data component mappings that should be checked against the current ATT&CK STIX bundle before rules are deployed.
| Telemetry | Signal to look for | Open-source collector | Confirm before deploying |
|---|---|---|---|
| Process Creation (DC0032) | Processes launched while a removable volume is mounted, especially archive, copy or sync utilities reading from the removable path | Sysmon Event ID 1 on Windows, auditd execve records on Linux, endpoint logs forwarded through Wazuh | Confirm that the current analytics for T1025 reference DC0032 in the STIX bundle for each platform you cover |
| File Access (DC0055) | Read operations against files on a removable drive, including bulk reads across many files in a short window | Sysmon file access auditing where configured, auditd file watch rules on Linux and macOS, Wazuh file integrity or audit feeds | File Access coverage varies by OS and by audit policy, so validate that read events are generated at the volume you monitor |
| Drive Creation (topic telemetry) | A new removable volume appearing on the host, with device identifiers and mount points recorded | Windows PnP and mount events forwarded to Wazuh, udev and mount logs on Linux, unified logs on macOS collected through Wazuh or Velociraptor | Confirm the exact data component name and ID for drive or volume creation in the ATT&CK version you target, since names can change between releases |
| File Creation (DC0039) | Files written to the removable drive from internal sources, which can show staging or copying onto media | Sysmon Event ID 11 on Windows, auditd write watches on Linux, Velociraptor hunts for new files on removable mounts | Confirm whether DC0039 is referenced for T1025 in your target version, and whether it is the right signal for copy-to-media activity |
| Command Execution (DC0064) | Shell or scripted commands that enumerate removable mounts or copy data from them | Wazuh command monitoring, auditd command records, PowerShell script block logging forwarded from Windows | Command-line content is often the weakest signal to rely on alone, so confirm how much of it your collectors retain |
| Removable media policy events | Device control allow or block decisions and removable storage access attempts recorded by the endpoint control | Endpoint device control logs forwarded to Wazuh or a Security Onion pipeline, depending on the control in place | Depends on a commercial or native control that is not open source in every case, so confirm what your environment already logs |
Detection logic for removable media collection on Linux, macOS and Windows
Removable media collection is hard to see in network telemetry because the data never leaves the endpoint over the wire. The detections below therefore rely on endpoint events: volume mounts, file reads and writes, and the timing and context around them. Each idea needs a documented baseline for the host group it covers, and each one should be tuned against approved workflows before it pages anyone.
Bulk reads after a volume mount
Alert when a removable volume mounts and a single user session then reads a large number of files from user profile or document directories within a short window. The threshold should come from your own baseline per host group, for example a count of files per minute compared with the normal reading pattern for finance or engineering workstations. Correlate the mount event with File Access telemetry on Windows, and with mount and file audit records on Linux and macOS. Tune against the baseline, not a fixed number. Expect false positives from antivirus scans, search indexers, and approved backup or sync clients that read widely before copying.
Copy activity outside business hours
Flag copy, sync or archive writes to a removable volume that occur outside the working hours recorded for the user's role and time zone. Define the window with HR or the business owner, then compare it with logon times from the directory. Low-volume writes at night can be normal for scheduled jobs, so require both an off-hours write and a data volume above the group baseline. Common false positives include scheduled imaging, approved overnight backup jobs and device management scripts that push files to USB-attached storage.
Volume creation on rarely used endpoints
Raise a finding when a removable volume appears on an endpoint group that has no recorded history of removable media use, such as servers, kiosks or hosts in restricted segments. Build the asset inventory first so that the rare group is defined from data, not assumption. Drive creation telemetry on Windows and mount events on Linux and macOS both support this check. Expect noise from laboratory hosts, forensic workstations and approved imaging stations, so maintain an allowlist tied to asset owner and change record.
Device control policy violations
Treat a write or read attempt blocked or logged by device control as a higher-priority signal than a plain mount event. Confirm with your endpoint tooling which device classes, vendor identifiers and actions it logs, because capabilities differ by product and platform. Pair the policy event with the user, the process that initiated access, and the file classification of the data touched. Exceptions approved for hardware vendors, field service or media production should be reviewed quarterly against the documented business need.
How to validate the removable media detection in a lab
This sequence turns the removable media detection for T1025 into a repeatable test, so the team knows which analytics fire on Linux, macOS and Windows, how quickly they fire, and where the gaps are before an adversary tests them for the team.
Agree scope and rules of engagement
The security lead, the detection engineer and the owner of the cyber range agree in writing which hosts, user accounts and removable media images are in scope, which platforms are covered, who approves each emulated action and how the test stops if production systems are affected. Data used in the exercise is synthetic or sanitized. The step is done when the signed scope document names the approver, the stop conditions and the systems that are excluded from testing.
Select and record the ATT&CK version
The detection engineer records the Enterprise ATT&CK version the test targets, along with the detection strategy IDs (DET IDs) and analytic IDs that map to T1025. Because releases can rename, deprecate or revoke techniques, the mapping is checked against the current version of the knowledge base before testing starts. Confirm the exact version and mapping against the ATT&CK updates pages. The step is complete when the version and the mapping table are stored with the test plan.
Define expected telemetry per platform
For each Linux, macOS and Windows host in scope, the team lists the data components the analytics depend on, such as Process Creation, File Access and Drive Creation, and the log sources that carry them, such as the Wazuh agent, Sysmon or the auditd and unified logging pipelines already in use. The expected event for each action is written down in plain language, with the fields that should appear and the index or stream where they should land. The step is done when every expected event has a named source and a reviewer has signed off on the list.
Prepare the range and baseline logging
The range team confirms that the endpoints, the removable media simulation and the log forwarding path are working, and captures a baseline period with no test activity. The baseline shows which removable media events already occur during normal use, so later alerts can be separated from routine noise. The output is a short baseline report listing event volumes per platform and any collection gaps found, such as hosts where a logging agent is missing or dropping events.
Run the approved emulation
An operator carries out the agreed emulation steps in the range, following the approved plan and not improvising outside the rules of engagement. The operator records the start and end time of each step, the host and account used and any deviation from the plan. Commands and tooling are kept in the restricted test record rather than in the shared report. The step is complete when the operator has logged every step and the stop conditions were not triggered, or were triggered and documented.
Record detections, latency and gaps
The detection engineer compares the expected telemetry with what reached the SIEM and which analytics fired. For each step the record shows whether the alert fired, the time from action to alert (latency), the severity assigned and whether the alert contained the fields needed for triage. Missing events and alerts that did not fire are listed as gaps with a likely cause, such as a logging policy, a rule condition or a parsing failure. The output is a results table with one row per expected event.
Store results against detection and analytic IDs
Each result is filed under the detection strategy and analytic IDs it validates, along with the ATT&CK version, the platform, the range build and the date of the run. This lets the team trace a rule back to the test that proved it and show an auditor or leadership which controls were exercised. Gaps are opened as tracked work items with an owner and a retest date. The step is done when the results are stored in the team's repository and the open gaps are linked to the rules they affect.
Retest after tuning and track drift
After rules are tuned or log sources are fixed, the same test is repeated on the same platforms so the before and after results can be compared. The team also reviews results when ATT&CK releases change the technique or its mappings. Confirm with your platform and SIEM vendors how rule versions and log schema changes are tracked in your environment. The step closes the loop when each gap is either resolved with a passing retest or formally accepted with a documented reason.
Preventive controls that limit removable media data loss
Detection tells you that data left on removable media, but preventive controls decide how much data can leave in the first place. The cards below cover the ATT&CK mitigation Data Loss Prevention (M1057) and the supporting mitigations Encrypt Sensitive Information (M1041) and Audit (M1047) that shape what an adversary can collect from a USB device.
Device control policy
Device control decides which removable devices can mount on an endpoint, and under what conditions. Policy can allow only approved device classes, block mass storage by default, or permit writes only for registered serial numbers. For T1025 Data from removable media, the key question is whether an unregistered USB drive can read or write corporate data at all. Confirm the default action for unknown devices on Windows, macOS and Linux endpoints, and test it on a non-production image before rollout. Also confirm how exceptions are approved and logged.
Content inspection on copy
Content inspection checks what is written to removable media, not only whether the device is allowed. Inspection engines look for patterns such as account numbers, health identifiers, source code markers or classification labels before a write completes. This matters because an authorized USB drive can still carry regulated data out of the building. Confirm which file types and archive formats your DLP product inspects, and whether it can block, warn or quarantine a copy.
Data classification labels
Content rules work best when files carry a reliable classification. Without labels, DLP engines rely on pattern matches that miss unstructured documents. Ask which labeling scheme your teams use, whether labels are applied automatically or by users, and whether removable media rules read the same labels as email and cloud rules. Mismatched labeling between channels is a common gap, so review rule coverage across all three before relying on removable media controls.
Encryption of removable media
The mitigation Encrypt Sensitive Information (M1041) reduces the value of a lost or stolen drive. Full-disk or container encryption on removable media means a copied file is unreadable without the key. Confirm whether your policy forces encryption before a write is permitted, who holds recovery keys, and how keys are rotated when a device is retired. Encryption does not stop a determined insider from copying data before it is encrypted, so pair it with device control and inspection.
Audit of device and copy events
The mitigation Audit (M1047) makes preventive decisions reviewable. Log device connection events, blocked writes and policy exceptions, and forward them to the central logging platform. Without these records, a blocked attempt cannot be distinguished from a device that was never tested. Confirm that audit logs include the device identifier, the user, the file names or hashes, and the policy action taken. Retention periods should be set by your own legal and compliance requirements.
User training and access scope
Preventive controls fail when users have more access than their role needs. Limit which accounts can change device policy, and which groups can write to removable media. The mitigations User Training (M1017) and User Account Management (M1018) support this by setting expectations and by reviewing privileges. Confirm who can override a block, how overrides are approved, and whether these reviews happen on a fixed schedule that your compliance program recognizes.
What the SOC does when a removable media alert fires
When a removable media alert fires for T1025 Data from removable media, the SOC's first job is to decide whether the event is a policy exception or a probable data loss. Start by confirming the device identity: vendor, product, serial number and the device class the endpoint reported at mount time. Then confirm the user account, the host, and the time window, and check whether the device appears in the approved inventory or the endpoint management records. Next, establish the business justification with the user's manager or the data owner, and confirm the data classification of the files that were read or copied. A file-access event touching a restricted dataset carries very different weight from one touching a public working folder, so the classification determines how fast the case moves.
While the triage questions are open, preserve endpoint evidence before anything changes on the host. Capture the process tree, the file access records and the device mount history from the endpoint telemetry, and export them to case storage with hashes so the record survives later tuning. Do not reimage or reboot the endpoint until the evidence is collected. For containment, decide whether to block the device class or the specific serial number through the endpoint policy, and record who approved the block and when it expires. Escalate to the data loss prevention or insider risk team when the classification is sensitive, when the justification is missing or inconsistent, or when the user is leaving the organization. Confirm with your own legal and HR owners which escalations need their involvement, since those routes differ by organization.
Close each case with a short record of what was confirmed, what was contained and what the outcome was. Feed the lessons back into detection tuning: approved devices that generate repeated false positives should move into an inventory-based allowlist with an owner and a review date, while gaps such as copies that the rule missed should become new test cases in the cyber range. Track the ATT&CK version the rule targets, because technique and data component changes in new releases can alter what the rule covers. Ask your detection engineering team to confirm which telemetry fields are populated on each platform before trusting a closed case as evidence of coverage.
Rehearsing removable media detection in a private cyber range
The range for Linux and macOS should mirror the production build of the endpoints that handle sensitive data, with the same audit configuration, agent versions and mount behavior. A small topology works well: one or more managed workstations with a Wazuh agent or equivalent collector, a log forwarder, and a Security Onion or Zeek sensor on the segment that carries file share traffic. Simulated user roles should include a standard analyst who is allowed to mount removable volumes and a restricted account that is not. Injects should include a staged removable volume with a set of records labeled as synthetic, followed by a bulk copy from a sensitive directory to that volume, so the team can see what the mount, the file access and the copy each produce in telemetry.
- Topology: Keep the endpoints in an isolated VLAN with no route to production, and record the exact kernel and macOS versions used.
- Simulated roles: Assign one user permitted to mount volumes and one restricted user, so both allowed and denied paths are tested.
- Injects: Stage a removable volume with synthetic data, then run a bulk copy from a monitored directory.
- Good detection: Mount events, file access on the monitored path and the copy operation appear in the SIEM within the expected window, mapped to the Process Creation and File Access data components.
- Good response: The analyst can identify the user, device and volume serial within the first triage cycle.
Before the exercise, confirm with your platform team which audit rules and mount logging your distribution provides, since capability differs by version.
The Windows range should include domain-joined endpoints, a domain controller, and a Wazuh or equivalent agent collecting Windows event logs with Sysmon or a comparable endpoint sensor. Drive creation and file access events depend on audit policy and sensor configuration, so the team should verify those settings in the range before running injects. Simulated users should include a standard employee, an administrator and a service account, since each can produce different removable media activity. The injects should include plugging in a staged USB volume, copying a folder of synthetic sensitive files to it, and then attempting the same copy under a denied policy, so the detection and the preventive control can be compared.
- Topology: Use at least one domain controller, a file server and two workstations, all forwarding logs to the same SIEM.
- Simulated roles: Include a standard user, an administrator and a service account with different removal privileges.
- Injects: Attach a staged USB volume with synthetic data, perform a bulk copy, and repeat the copy after a device control policy is enabled.
- Good detection: Drive creation, process creation for the copy tool and file access on the sensitive share correlate to one user session.
- Good response: Data loss prevention blocks or logs the second attempt, and the alert reaches the SOC with the device identifier.
Confirm with your Windows team which device control and audit subcategories are enabled in the range, because these settings determine which events exist to detect.
The SOC response tab covers what the analysts do once telemetry arrives. The team should work from a written playbook that names the detection rule, the data components involved and the decision points for escalation, and should practice with the same synthetic injects used by the platform tabs. The exercise should also test handoffs: from the SOC to the endpoint team for device isolation, and from the data owner to the compliance lead if synthetic records are marked as regulated. An illustrative timeline for a single inject might begin with alert triage, followed by user and device confirmation, containment of the device session, evidence preservation and a closing review of whether the data loss prevention control fired. Teams should record how long each step took in their own range, since no benchmark is supplied for that.
- Playbook: Document the rule name, the telemetry sources and the escalation thresholds before the exercise starts.
- Triage: Confirm the user, device, volume identifier and the set of files touched.
- Containment: Practice blocking the device session and disabling the account in the range without touching production.
- Evidence: Preserve logs, file lists and hashes of synthetic files for the review.
- Review: Compare the detection time, the response steps and any gaps in data loss prevention coverage, then update the rule.
End the exercise by confirming that the detection rule targets a named ATT&CK version, since mappings change between releases.
Questions SOC leads and detection engineers ask about T1025
How do we separate approved backup tools from exfiltration staging on removable media?
Separate them by context, not by the act of copying. Approved backup tools run from known paths, under known service accounts, on defined schedules, and against defined sources. Staging looks different: an unfamiliar process, an interactive user session, bulk reads from document or database locations, and writes to a removable volume outside a change window. Build an allowlist of backup binaries, hashes or signed publishers, and service accounts, then alert on anything that writes to a removable drive without matching that baseline. Confirm the exact fields your Wazuh or Sysmon pipeline emits before writing the rule, because field names differ between agents and versions.
Which telemetry do we need for T1025 on Linux, macOS and Windows?
The minimum is a record of when removable media is mounted or created and a record of which process then reads or writes files on it. On Windows, collect process creation events, file access auditing on sensitive paths, and drive or volume arrival events, then correlate by process and user. On Linux, collect process execution from auditd or equivalent, and mount events from the kernel audit or udev logs. On macOS, collect unified log entries for volume mounts and process execution through your endpoint agent. Map each source to the ATT&CK data components your detection strategy cites, and confirm each one is enabled and retained before you test. Coverage gaps usually come from file access auditing that was never turned on, not from missing tools.
How do we handle ATT&CK version changes in our T1025 detection mappings?
Record the ATT&CK version in every detection mapping and review it on each release. MITRE's update pages list the recent releases, including v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026. Releases can rename, deprecate or revoke techniques, and ATT&CK v18 moved detections into detection strategies and analytics, so a rule written against an older page may point to content that has changed. Pull the STIX bundle for the version you target, diff the T1025 objects and their data component references, and update your Sigma or Wazuh rule metadata. Keep the version in the rule file so auditors can see what the mapping was built against.
How do we tune false positives for removable media alerts without blinding the SOC?
Tune by narrowing the trusted context, never by suppressing the whole rule. Start by listing the legitimate sources of removable media in your estate: backup appliances, imaging stations, kiosk workflows, and approved vendor tools. For each, record the process, user group, device identifier and time window. Add those as exceptions with a review date and an owner. Keep the rule firing for unknown devices, for bulk reads of sensitive directories, and for any write to removable media from an unusual parent process. Track the alert volume and the proportion closed as benign each week, and review exceptions quarterly so they do not become permanent blind spots.
How do we test T1025 detections without disrupting users or production systems?
Test in a private cyber range or an isolated staging segment that mirrors your endpoint agents, log pipeline and removable media policies, but holds no production data. Use synthetic files that carry canary markers, not real customer records, and run controlled copy operations on test endpoints during an agreed window. Confirm that each event reaches your SIEM, that the rule fires with the expected severity, and that the response playbook opens the right ticket. Document each test case with the ATT&CK version, expected telemetry and result, so the evidence can be reused in compliance reviews. Only move a rule to production after the same test passes on a production-like endpoint.
What should we ask a partner to confirm before scoping T1025 detection work?
Ask the partner to confirm which operating systems, endpoint agents and log sources are in scope, and which ATT&CK version the detections will target. Ask how they will validate each rule in a cyber range before production, and what evidence they will hand over, such as test records, rule files and tuning logs. Confirm who owns ongoing tuning and ATT&CK version updates after handover. DeployOpen implements and tests open-source detection platforms inside the client's own environment and works under a fixed written scope, so the scope document should list each OS, log source and test case explicitly. Ask for those items in writing before work starts.
How DeployOpen builds removable media detections and range scenarios
DeployOpen works on T1025 Data from removable media as a fixed-scope engagement inside your own environment. We agree what is covered in writing, build the detections on open-source tooling, and rehearse them in a private cyber range before handover.
How we scope
- Agree in writing which operating systems, removable media controls and log sources are in scope for T1025.
- Confirm which ATT&CK version the detection mapping will target, since releases can rename or deprecate techniques.
- Record which Process Creation, File Access and drive creation telemetry your existing platform already collects.
How we build
- Write detection logic for Linux, macOS and Windows in words and map it to the relevant data components.
- Deploy the detection content into your own Wazuh, Security Onion or other chosen platform, inside your infrastructure.
- Tune rules against your normal removable media usage so that legitimate backup and imaging activity is understood.
How we hand over
- Test detections in a private cyber range using agreed, illustrative scenarios and record the results.
- Document the detection logic, data sources, validation steps and response actions in a form your team can maintain.
- Map supporting controls, including Data Loss Prevention (M1057), to evidence your compliance teams can review.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Review detections when ATT&CK releases change technique mappings or data component definitions.
- Ask your quote to name who maintains the rules, who reviews alerts and how changes are approved.
