How T1092 communication through removable media works in intrusions
Yes, removable media can carry command and control traffic. In ATT&CK Enterprise 20.0, T1092, Communication through removable media, sits under the Command and Control tactic (TA0011), which ATT&CK describes as adversaries trying to communicate with compromised systems to control them. The technique moves instructions and results on a device instead of over a network connection, so a SOC lead should ask a narrow question: can any host in the estate exchange data across a boundary through a USB drive, optical disc or other mounted volume? Network monitoring alone will not show that movement, because the device crosses the boundary outside the network path.
The technique matters most where networks are air-gapped or partly isolated, such as industrial control zones, lab enclaves and restricted research segments. These environments often block direct egress by design, so removable media becomes a practical way to move data between a connected host and an isolated one. Illustrative example: a maintenance laptop is used on both a corporate network and a controls network, and a removable device carries files between the two. The detection gap is the device movement itself, so the first decisions are which segments are truly isolated, which hosts still accept removable devices, and whether each of those hosts has a documented business need for them.
This page targets ATT&CK Enterprise 20.0, released by MITRE on October 13, 2026. Technique mappings can change between releases, because MITRE may rename, deprecate or revoke techniques, and the v18 update replaced technique-page detections with detection strategies and analytics. Before you build or tune detections, confirm the technique ID, tactic and data components against the version your rules target, using the ATT&CK updates page and your own rule records.
Which telemetry reveals removable media channels and which tool collects it
This table maps the Process Creation, File Creation and Drive Creation data components to the signal each gives for T1092, the open-source collector that captures it, and what that collector cannot see. Read each row as a separate signal, since no single source confirms removable media use on its own. Coverage differs by operating system, so confirm each collector's configuration in your own environment before relying on it.
| Data component and signal | Open-source collector and platform | What the collector cannot see |
|---|---|---|
| Drive Creation: a removable volume is mounted or appears on the host | Wazuh with auditd on Linux and macOS, Sysmon for Windows where device events are configured, osquery for mount state | Mount events on hosts without the audit rule or osquery table enabled, and removable media attached to hosts outside the collector's scope |
| File Creation: files are written to or created on a removable volume | Sysmon file creation events on Windows, auditd file watches on Linux, Velociraptor artifacts for file system state | Writes that occur before the agent starts, watches limited to configured paths, and content inside encrypted volumes |
| Process Creation: a process runs with a path, arguments or parent tied to a removable volume | Sysmon process creation on Windows, auditd execve records on Linux, Wazuh and osquery process listings on macOS | Processes launched from a mounted volume that do not log arguments, and activity from processes that exit before collection |
| Mount and unmount history on Linux and macOS | auditd mount-related rules via Wazuh, osquery mounts table, Velociraptor hunts over system logs | Mount activity captured only in logs the host rotates or never writes, and changes made by a privileged user with audit rules disabled |
| Device identity and USB history on Windows | Sysmon and Windows event logs collected by Wazuh, Velociraptor artifacts for removable storage history | Device serial details on systems where the relevant log channel is off, and devices that never generate a registry or event trace |
| Correlation with network activity and data movement | Wazuh and Security Onion for host and network context, Zeek file logs where traffic leaves the segment | Transfers that never cross the monitored network, such as air-gapped exchange between two hosts on the same bench |
Detection ideas for removable media channels, with tuning and false positives
Removable media channels are quiet by design, so detection depends on a few signals that are cheap to collect and easy to misread. The four ideas below pair an attachment event, a file event, a transfer pattern and an offline-host check, and each one needs a baseline before it can alarm. Every threshold here is a starting point to tune against the client's own device inventory and maintenance calendar.
Unapproved drive attachment
Alert when a USB mass storage device appears on an endpoint and its serial or vendor and product identifiers are absent from the approved device list. The signal comes from Drive Creation and device connection telemetry on Windows and from kernel or udev events on Linux and macOS. Tune the allowlist first, because a list built from asset records will flag every new peripheral from the first day. Main false positives: approved imaging stations, backup enclosures, and conference room kiosks that were never enrolled.
Files written to removable volumes
Flag File Creation events on a removable volume where the writing process is not on a short list of expected applications, such as the approved backup agent or the vendor imaging tool. Compare the process image path, signer and parent process against the baseline for the host group. Set a per-host threshold of new files per hour, starting high, and review any archive or encrypted container written by a process that normally never touches external storage. Main false positives: office suites saving documents to a USB drive, and scheduled exports from line-of-business software.
Repeated transfers between shared drives
Look for the same removable volume, identified by serial number, appearing on several hosts within a short window, with file writes on one host followed by reads on another. This pattern is the closest match to a removable media channel between two systems that have no direct network path. Start with a window measured in hours, not minutes, and require at least three distinct hosts before alerting. Main false positives: shared training laptops, field technicians moving firmware images between sites, and kiosk refresh workflows.
Drive activity on offline systems
Alert on any removable drive attachment or volume mount on a host that is classified as offline, air-gapped or restricted, such as a control system workstation or a segregated lab machine. Because these hosts should show no normal removable activity, even a single event is worth a review. Confirm the classification source is current, since a host moved between zones without an inventory update will look like a violation. Main false positives: approved maintenance visits, vendor patch media, and lab workflows that intentionally load test data.
How to validate the T1092 detection in a lab before production
This sequence proves that the T1092 detection fires on a benign, authorized emulation in a private lab or cyber range, and it produces a documented record of timing, hits, misses and noise before any rule reaches production.
Confirm written authorization and scope
Before any emulation, the asset owner, the security lead and the range operator agree in writing on the systems in scope, the test window, the hosts that may be touched, the removable media types allowed and the stop conditions. The emulation runs only on lab or range hosts that the organization owns or controls. The step is complete when the signed scope document names every host and drive type and the rollback owner is reachable during the test window.
Define the benign test scenario
The team writes a scenario that describes what a removable drive is expected to do in the test, such as a user attaching a labeled test drive and moving a harmless marker file, followed by a supervised eject. The scenario should be written in plain language without commands, payloads or evasion steps, and it should state the expected business reason for the activity. The step is complete when a reviewer who did not write it can reproduce the intent and confirm that it is benign.
Set up hosts and drive types
Prepare a small, representative set of Linux, macOS and Windows lab endpoints that match production builds, with logging agents and the detection pipeline active. Record the drive types used, including USB flash drives, external disks and any device classes that production users rely on, along with their vendor, capacity and volume labels. The step is complete when an inventory lists each host, operating system version, agent version and drive type, so later results can be traced to a known configuration.
Document expected telemetry per platform
For each platform, write down the telemetry the team expects to see: drive creation or mount events, file creation events on the removable volume, and process creation events for the processes that touched it. Mark which data sources are available on each platform and which are not, so gaps are visible before testing begins. Confirm the exact event names and field mappings in the chosen SIEM or log pipeline, because the available telemetry depends on each platform's logging configuration. The step is complete when every expected event has a source, a field and an owner.
Set pass criteria before the run
Agree on pass criteria before the scenario runs: the expected events are present in the log store, the detection rule produces an alert on the intended hosts, the alert contains the fields analysts need to triage it, and the alert reaches the correct queue within the response target the team has already set. Also define what counts as a miss and what counts as an acceptable false positive during the test. The step is complete when the criteria are signed off and no one can change them after the run starts.
Run the emulation and record timing, hits and misses
Execute the benign scenario under observation, with a scribe logging the time of each action, the time each event appears in the log store, and the time each alert fires. Record every rule hit, every missed action and every unrelated alert that appears during the window. Compare these timestamps to show ingestion delay and alert latency. The step is complete when the timeline shows each scenario action paired with its telemetry, alert and any gaps.
Review noise and tune the rule
Analysts review the results with the rule owner and classify each alert as a true test hit, a miss, or unrelated noise from normal activity on the same hosts. Adjust the logic, thresholds or allowlists only where the evidence supports the change, and record the reason for each change alongside the version of the rule. Keep the tuning narrow so that the rule still covers the benign scenario and the production behavior it is meant to catch. The step is complete when each change has a documented reason and a before and after result.
Re-run after tuning and retain evidence
Repeat the same scenario on the same hosts and drive types after tuning, using the same pass criteria, and compare the results with the first run. Keep the scope document, the scenario, the telemetry map, the timeline, the tuning log and both result sets together in a versioned evidence folder. The step is complete when the second run meets the pass criteria, the evidence is stored for review, and the team decides whether the rule is ready for production or needs another cycle. Confirm with the auditor or compliance lead which evidence format they accept.
Preventive controls that reduce removable media risk
Preventive controls shrink the number of systems where T1092 Communication through removable media can take hold. The cards below pair the ATT&CK mitigation Disable or Remove Feature or Program (M1042) with operating system configuration, so detection has fewer legitimate exceptions to sort through and fewer paths to watch.
Restrict removable storage by device class
Start by deciding which device classes (mass storage, optical media, portable devices) are needed for each system role, then disable the rest through the operating system's device control policy. Restricting by class, not only by individual device, keeps a newly plugged-in unapproved drive from becoming a ready channel. Confirm each platform's device control options in its vendor documentation, since the available settings differ between Windows, macOS and Linux and may depend on the management tooling in place.
Remove unneeded drivers and services
Disable or uninstall the kernel modules, drivers and removable media services that a system does not use, which is the practical meaning of M1042 for this technique. On Linux this often means blacklisting storage modules through configuration, and on Windows it means reviewing installed device drivers. Test each removal on a non-production image first, because a removed driver can break backups, imaging or hardware monitoring.
Define the exception process
Every restriction will meet a legitimate need, such as a vendor appliance that needs a USB key for updates. Write an exception process that names the approver, the business reason, the device identifier, the expiry date and the monitoring that applies while the exception is active. Exceptions with no expiry tend to become permanent gaps, and detection teams should receive every approved exception so they can tune alerts.
Weigh operational trade-offs
Restrictions have costs that fall on operations teams: field technicians cannot load firmware, forensic staff cannot image a drive on a locked workstation, and some industrial or medical devices depend on removable media for updates. Discuss these cases with system owners before enforcement, and plan a staged rollout that starts with the systems where removable media has the least business value.
Verify settings with configuration checks
A policy that exists on paper is not a control until it is observed on endpoints. Use configuration assessment or endpoint management reports to confirm that device restrictions and disabled modules are applied as written, and track drift after patches or re-imaging. Retain these reports as evidence of the operating system configuration you intended to enforce.
Triage steps when a removable media detection fires
The first decision on a removable media alert is whether the device is a known, approved asset or an unknown one, and that check should happen before anyone touches the host. Confirm the device identity from the alert itself (vendor, product, serial number and volume label where the telemetry records them), then match it against your approved device register, asset inventory and endpoint device control policy. Identify the registered owner and the user logged on at the time, and ask that person directly whether they expected the device to be connected. A device that is registered, owned and expected closes quickly. A device that is unregistered, unowned or connected outside working hours moves the case forward. Record the answers in the ticket with timestamps so the decision trail survives a later review.
Next, establish what was written to the device and by which process. Using the File Creation and Process Creation telemetry that fired the alert, list the files, their paths, sizes and hashes, and the parent and child processes that wrote them. Check whether the write came from an interactive user action, a scheduled job, a backup agent or an unfamiliar binary. Then scope other hosts: search your endpoint and log platform for the same device serial number or volume identifier across the estate for the past period your retention allows, and note every host that mounted it. Preserve evidence before any cleanup. Capture the relevant logs and file metadata, take a forensic image of the affected endpoint if the case warrants it, and do not reformat or wipe the device until the custodian has agreed in writing.
Containment should be proportionate and decided with the data owner, not only by the security team. Options include blocking the device class or serial number through your endpoint policy, isolating a single host, or disabling the user's removable storage pending review. Confirm with the business owner of any data that may have left the environment, because they will need to assess notification obligations and customer impact under their own regulatory framework. Escalate to incident response when the device is unregistered and carries files you cannot account for, when sensitive data classes appear in the written set, when the same device appears on several hosts, or when the process that wrote the files cannot be explained. Confirm your escalation thresholds, retention periods and evidence handling procedures with your legal and incident response leads before the first alert arrives.
Rehearsing T1092 detection and response in a private cyber range
A private cyber range for T1092 needs isolated endpoints that behave like the real fleet, a central pipeline that receives their logs, and removable device telemetry that is actually switched on. Build the range inside your own network or an isolated cloud segment with no route to production, and use the same operating system versions your endpoints run. Include one Linux, one macOS and one Windows host so the exercise tests platform-specific logging rather than a single pattern.
- Isolated hosts: Place endpoints on a segment with no route to production, and snapshot them before each run so every exercise starts from the same state.
- Pipeline: Forward endpoint events to a Wazuh or similar pipeline, and confirm that events arrive with host, user and device fields intact.
- Removable device logging: Enable the auditing or device control events each platform offers, and record which ones are on before the exercise starts.
- Time sync: Synchronize all endpoints and the pipeline to one time source so alert timing can be measured accurately.
- Baseline: Record normal removable media use in the range so analysts know what a quiet day looks like.
Before scheduling, confirm with your platform team which device logging options are available on each operating system version in your fleet.
Injects are scripted events the facilitator triggers so the blue team has something concrete to detect. Keep each inject small and label it clearly as illustrative in the exercise plan. Three injects cover the core T1092 situations and let you compare how each platform's telemetry responds.
- Approved device inserted: An approved, registered device is connected to a range endpoint. The expected result is a logged event with no alert, which tests whether analysts can tell approved use from suspicious use.
- Unapproved device inserted: An unregistered device is connected to a Windows, macOS or Linux host. The expected result is a device event that reaches the pipeline and matches the detection logic your team has documented.
- File write to a removable volume: A file is written to a removable volume after the device is mounted. The expected result is file creation telemetry tied to the device, with the process and user recorded.
- Timing variations: Repeat one inject with the device removed quickly and again with it left mounted, to see whether the detection still fires.
- Facilitator log: Record the exact time of every inject so detection timing can be scored against the true event time.
Check with your team that each inject is permitted under your acceptable use policy before the exercise runs.
A good exercise is judged on what the blue team does with each alert, not only on whether one appeared. Score three areas: how quickly the alert appears after the inject, how well the analyst triages it, and whether evidence is handled so it can be used later. Agree the scoring criteria with the facilitator before the exercise, so the results are comparable across runs and across platforms.
- Alert timing: Measure the gap between the facilitator's timestamp and the alert's arrival in the pipeline, and note any platform where the gap is large or the alert never fires.
- Triage quality: Check whether the analyst identifies the host, user, device and process, and whether they separate an approved device from an unapproved one.
- Evidence handling: Confirm the analyst records the device identifiers and related file events, preserves logs before they roll over, and avoids altering the endpoint before capture.
- Response steps: Check whether the analyst follows the documented playbook, including containment decisions and escalation to the correct owner.
- Debrief: Capture gaps as tuning or logging tasks with owners, and retest them in the next run.
Confirm your own alert timing and evidence retention targets with your security operations lead before using any of them as pass criteria.
How detection logic maps to ATT&CK version 20.0 and later releases
Every detection we write for T1092 Communication through removable media should name the ATT&CK version it targets, and for this page that version is Enterprise ATT&CK 20.0, taken from the enterprise-attack 20.0 STIX bundle in the mitre-attack/attack-stix-data repository. The link between a rule and the technique is not the technique name alone. We record the detection strategy identifier, the analytic, the data components the analytic reads (such as Drive Creation, File Creation and Process Creation for this technique) and the mitigation the rule supports. Because ATT&CK v18 replaced technique-level detections with detection strategies and analytics and reworked data components, a mapping that cites only the technique ID cannot be checked against a specific release. Pinning the version keeps the mapping auditable.
The practical step is to confirm each mapping against the bundle for the version you have pinned, not against memory or a blog summary. Open the STIX file for enterprise-attack 20.0 and locate the T1092 entry, then confirm which data components and detection strategies are referenced, and whether the technique is still active. Ask whether any sub-technique, revocation or deprecation affects your rules. Record the bundle name, the version and the date you checked, so an assessor can repeat the check. Your own inventory of data sources should also be compared against those data components, because a detection that depends on telemetry you do not collect is not a detection in your environment.
After each release, plan a recheck before you update the pinned version. The ATT&CK updates pages publish release notes for each version, including the v18 notes from October 2025, the v19 notes from April 2026 and the v20 notes from October 2026. Read the notes for changes to T1092, its data components and its mitigations, then diff the new STIX bundle against the one you pinned. Where a rule's mapping changes, update its metadata, rerun the validation tests described in the cyber range exercise, and keep the previous mapping in version control. Confirm the recheck cadence, owner and sign-off with your security engineering and compliance leads before the first release cycle begins, since releases can rename, deprecate or revoke techniques.
Questions SOC leads and detection engineers ask about T1092
Which telemetry is most reliable for drive creation on each operating system?
No single log source covers drive creation on all three platforms, so the answer depends on what your endpoint agent collects and at what verbosity. On Windows, process creation events and file system activity for newly mounted volumes give the clearest trail. On Linux, mount activity and device events collected through audit rules are the usual starting point. On macOS, unified log entries about volume mounts and the Endpoint Security framework feed used by some agents are the sources to check. Confirm each source in your own environment before you write a detection against it, because default logging levels and retention vary by OS build and agent version.
How do we reduce alert noise from approved imaging and backup tools?
Reduce noise by building an allowlist that identifies approved tools by signed publisher, file hash and host group, and then alerting on exceptions rather than on the tool itself. Three checks keep the allowlist honest:
- Tie each approved workflow to a change or service record so an unexpected run is visible.
- Alert when an approved tool writes to removable media outside its usual schedule, volume or host group.
- Alert when removable media activity is followed by a process that is not on the approved set.
Review the allowlist after each software update to the imaging or backup product, because a new version can change the binary hash or the paths it uses.
Can network telemetry see communication through removable media?
Network sensors cannot see data moving across a physical device, so they will not observe the removable media exchange itself. They can still help you confirm the outcome when data taken from removable media is later sent over a network. Correlate endpoint events with Network Connection Creation (DC0082), Network Traffic Flow (DC0078) and Network Traffic Content (DC0085) data from your Zeek or Suricata sensors to see whether a host that recently mounted removable media then opened unusual outbound sessions. Treat this as a supporting signal, because many hosts in regulated environments are not connected to the network in the first place and the risk is concentrated on the endpoint.
How do we test T1092 detections without risking production systems?
Test in a private cyber range that mirrors your endpoint builds, logging configuration and SIEM pipeline, and use synthetic removable media images and canary files instead of real business data. Write a test plan that names the expected alerts, the hosts involved, the time window and the rollback steps before the exercise starts. Record which events arrived, how long they took to reach the SIEM, and which fields were missing. Repeat the test after any change to the agent, the OS image or the detection logic, so you can show that the detection still fires. DeployOpen runs private cyber ranges and can build this exercise as a fixed-scope engagement with written deliverables.
How often should we revisit our T1092 mapping after ATT&CK updates?
Review the mapping at every ATT&CK release, because releases can rename, deprecate or revoke techniques and change how detections are described. The ATT&CK v18 release on October 28, 2025 replaced detections in technique pages with detection strategies and analytics, and later releases followed the same pattern, so a rule written against an older page may no longer match the current guidance. Record the ATT&CK version in every rule's metadata, compare the new STIX bundle against your previous version, and check the ATT&CK updates page for renamed or deprecated items before you change production content.
Which mitigations should we prioritize for removable media channels?
Start with Disable or Remove Feature or Program (M1042), which ATT&CK maps to several command and control techniques, and with operating system configuration that controls how removable media is mounted and which device classes are accepted. In practice, this means turning off automatic mounting where it is not needed, restricting device classes through endpoint policy, and documenting exceptions with an owner and an expiry date. Confirm with your endpoint platform vendor which controls it supports and how it reports policy violations, because the exact settings differ by OS and product. Pair these controls with the detections above so that a blocked device still produces a logged attempt.
Can our own team run T1092 detection, or do we need outside help?
Your team can run this detection if it already has endpoint logging collected centrally, detection engineers who can maintain Sigma or SIEM rules, and a test environment where changes are validated before release. Outside help is most useful for the initial design, the cyber range exercise and the handover, which are usually well suited to a fixed scope with agreed deliverables. Ask any provider to state in writing which systems they will touch, who keeps the rules after handover, and what evidence you receive. DeployOpen implements open-source security platforms inside your own infrastructure and prepares evidence for compliance assessments, but it does not issue audit reports or certifications, so independent assessors still review your controls.
How DeployOpen builds T1092 detections and range scenarios
DeployOpen approaches T1092 Communication through removable media as a written, fixed-scope engagement inside your own environment. The work covers telemetry review, detection logic for Linux, macOS and Windows, and rehearsal in a private cyber range before anything reaches production.
How we scope
- Agree in writing which operating systems, removable media controls and telemetry sources fall within the T1092 engagement.
- Confirm which ATT&CK version the detection mappings will target, since releases can rename or deprecate techniques.
- Record which Process Creation, File Creation and Drive Creation sources your endpoints already produce, and which must be added.
How we build
- Write detection logic in plain language first, then translate it into open-source rules for your SIEM or Wazuh deployment.
- Map each detection to the ATT&CK mitigations for T1092, including Disable or Remove Feature or Program and Operating System Configuration.
- Prepare test cases for benign removable media use so analysts can separate legitimate activity from suspicious patterns.
How we hand over
- Deliver detection rules, test results and range scenario runbooks with the version of ATT&CK they target.
- Document the response steps analysts should follow when a removable media alert fires on a monitored endpoint.
- Provide a handover session so your security operations team can run the range scenario and tune thresholds independently.
How we support
- Ongoing support, upgrades and continuous testing for T1092 detections are available as a retainer, agreed separately.
- Re-validate rules when ATT&CK releases change technique content or when your endpoint telemetry configuration changes.
- Ask any provider to confirm the scope, deliverables and timelines in writing before work begins, including what is excluded.
