How T1091 replication through removable media moves an intrusion across hosts
T1091 Replication through removable media is the technique where an adversary spreads by copying itself or its tooling onto USB drives and other removable media, then relying on a person or an automated process to move that media to another system. Under the Lateral Movement tactic (TA0008), ATT&CK defines the goal as: "The adversary is trying to move through your environment." For a SOC lead, the risk is not only the first infected host. It is the chance that a drive carries the intrusion across an air gap, a segmented operational network or a restricted enclave where network-based controls see nothing. This page targets Enterprise ATT&CK version 20.0, so mappings and sub-technique references should be checked against that version before they are used in detection content. MITRE ATT&CK tactic TA0008 describes the tactic and is the right starting point for the wider context.
At a high level, removable media spreads an intrusion through a simple loop. A drive is written to on a compromised host, carried or handed to another system, and then mounted there. The spread often depends on Windows features such as autorun behavior, shortcut files or user double-click habits, so the first question for a defender is which of those paths are still enabled on your fleet. Removable media typically shows up in intrusions at points where people move between zones: maintenance laptops, engineering workstations, kiosk terminals, data transfer stations and shared test rigs. Confirm with your endpoint team which device classes can mount removable storage, which of them sit on segmented networks, and whether any of them are excluded from the USB and device control policies you rely on elsewhere.
The practical decision is where removable storage is allowed to exist at all. Before writing detections, ask who owns the approved transfer process, how drives are issued and logged, and whether a registered device inventory exists. Those answers determine whether a new device on a host is an alert, a policy violation or routine work. Ask your vendor or internal platform team to confirm how the detection stack records device insertion and file creation on removable volumes, because the answer changes which telemetry you can rely on in the sections that follow.
Which Windows telemetry reveals removable media replication
This table maps three Windows telemetry sources, Process Creation, File Creation and File Access, to the signal each one gives when a removable volume is used to spread files or launch code. Read each row as a question the sensor can answer, then confirm the audit settings that make that answer available in your environment. The main takeaway is that no single source is enough, so detection depends on combining the three.
| Telemetry source | Signal it provides for T1091 | Open-source collector | What to confirm in the client environment |
|---|---|---|---|
| Process Creation | Processes started from a removable drive letter, or with a removable volume as the working directory (illustrative: a launch from a drive letter that was not present at logon) | Sysmon process creation events forwarded to Wazuh or Security Onion; Windows Security event 4688 as a fallback | Whether command-line auditing is enabled, and whether Sysmon is deployed on all endpoints that accept removable media |
| File Creation | New executables, scripts or shortcut files written to a removable volume, and autorun-style file names such as autorun.inf appearing on removable media | Sysmon file create events forwarded to Wazuh or Security Onion, with rule filters on removable volume paths | Which file types and paths the Sysmon configuration captures, and whether removable drive letters are mapped consistently across the fleet |
| File Access | Reads or writes against files on a removable volume that a user or process did not normally open, such as bulk copying from a shared folder onto media | Windows object access auditing for removable volumes, with events shipped to Wazuh through the Windows event channel | Whether object access auditing is enabled through group policy, and whether the audit scope and log volume have been sized for the endpoints in scope |
| Device connection context | Timing that links a removable device arrival to the file and process events that follow, which helps separate a user copying files from a process copying them | Windows event logging and Sysmon events correlated in Wazuh or Security Onion by host and time window | Whether the device arrival is logged on the endpoint, and how long events are retained for correlation |
| Removable media policy events | Records of which removable device classes were allowed or blocked, which shows whether a replication attempt reached the endpoint at all | Windows event logs from the device installation and policy components, forwarded to Wazuh | Whether the client's device control product writes events the SIEM can read, and whether those events are retained |
| Analyst validation | Confirmation that alerts reflect real removable media activity and not normal backups, software installers or imaging tools | Velociraptor collection of removable volume contents and process history from the affected host | Approved exception lists and the owners who can confirm legitimate removable media use |
Detection logic for removable drive replication on Windows
T1091 relies on a removable volume acting as the carrier between hosts, so the useful signals sit where a USB drive is mounted, executed from and written to. The cards below describe four detection ideas built on Process Creation (DC0032) and File Creation (DC0039) telemetry, each with the tuning question and the benign activity that will trigger it.
Executables and scripts created on removable volumes
Flag file creation events where the target path sits on a removable drive letter and the extension is an executable, script or shortcut type, such as .exe, .scr, .bat, .vbs, .js, .ps1 or .lnk. Tune the extension list to your environment and alert on new objects, not overwrites of files already present on the stick. Expect false positives from software installers, portable application suites and developer tooling that copy binaries to removable media. Confirm the approved list with the owning team before alerting on it.
Processes launched from removable drive letters
Alert on process creation events whose image path resolves to a removable drive letter, paired with a parent process that is an interactive shell or Explorer. A process started from removable media is a strong signal because legitimate software rarely runs directly from a stick. Tune by excluding known portable tools and by suppressing alerts for encrypted volumes that an approved utility mounts. Review the parent-child relationship before escalating, since a single launch is weaker evidence than a launch followed by network or persistence activity.
New autorun-related files on removable media
Watch for file creation of autorun configuration files, such as autorun.inf, at the root of removable volumes, and for any hidden or system attributes applied to new files on those volumes. Autorun artifacts are a common way replicated copies are set to run on insertion, so a new file here deserves review even when no executable accompanies it. Benign sources include some vendor media and device manufacturer utilities. Record the vendor baseline for each approved device class so that expected autorun files are suppressed explicitly.
Bursts of writes across many removable volumes
Count distinct removable volumes receiving file creations from one host within a short sliding window, and alert when the count exceeds the threshold you set for normal operations. Replication often writes the same artifact to several drives in quick succession, so distinct-volume counts are more telling than raw write volume. Backup software, imaging tools and bulk copy jobs trigger this logic, so exclude their service accounts and known workstation roles. Agree the threshold and window with the endpoint team and document both in the detection record.
How to validate that the T1091 detection fires
This sequence proves, in a private cyber range, that the T1091 detection fires on a benign removable media replication simulation, and it records the telemetry, false positive results and ATT&CK and rule versions needed to trust the alert. It turns a written detection into evidence that a SOC can rely on.
Agree the rules of engagement
The detection owner, SOC lead and range operator agree in writing what the benign replication simulation covers, which test host and user account will be used, the time window in which the alert is expected, and who may stop the exercise. The simulation must stay within the agreed scope and must not touch production endpoints or real business data. The step is done when the signed rules of engagement name the ATT&CK version and the detection rule version under test, so the results can be tied to exact content later.
Prepare a logged Windows test host
The range team builds a Windows test endpoint that mirrors the production baseline, with process creation auditing, file system auditing on the locations the detection watches, and the forwarding agent (for example, Wazuh or Sysmon-based collection) sending events to the SIEM. They confirm that test events from a known benign action reach the SIEM with the expected fields before the exercise starts. The step is done when a baseline check shows the Process Creation and File Creation telemetry arriving with timestamps, host name and user context intact.
Run the benign replication simulation
A designated operator, following the agreed plan, performs a benign simulation that represents the removable media behavior the detection targets, such as an approved test volume being attached and a copy-type file event occurring on the test host. The operator does not use attack tooling or payloads, and they log the start and end time of each action. The step is done when the operator's activity log matches the agreed simulation steps one for one, with no unplanned actions.
Confirm the alert fires in the window
The SOC analyst checks the SIEM for an alert from the detection rule within the agreed window. They compare the alert time with the operator log to confirm it corresponds to the simulation and not to unrelated activity. If no alert fires, the team records the gap and reviews whether the log source, rule logic or field mapping failed. The step is done when the alert, its rule identifier and its trigger time are captured in the exercise record.
Record the matched telemetry fields
The analyst documents which telemetry fields the alert matched, such as the process name, parent process, file path, volume identifier, user account and host name, and notes any field that was missing or empty. This shows whether the rule depends on fields that the endpoint configuration reliably produces. The step is done when a field-by-field table exists for the alert, with each value traced back to a raw event in the SIEM.
Test false positives on approved media
The team repeats the exercise using approved removable media that the organization already permits, such as encrypted company drives used in normal workflows, and records whether the rule fires. They also review a sample of routine removable media activity from the baseline period. Each alert is classified as true positive, expected benign or unexplained. The step is done when every false positive has a documented cause and a proposed tuning change, or a recorded decision to accept it.
Document versions and close the exercise
The team records the ATT&CK version the mapping targets, the rule version and commit, the telemetry configuration and the range build, and files them with the exercise results. Any tuning is tested again in the range before it reaches production, and the result is stored for the next review cycle. The step is done when a single record links the ATT&CK version, rule version, test date, operator log, alert evidence and false positive decisions, and the detection owner signs it off.
Why detection engineering for T1091 needs asset and media context
Removable media detection only works when the detection team knows which hosts are supposed to use USB storage, which drives are approved for those hosts, and where data is allowed to leave the environment. Without that baseline, every new drive insertion or executable written to a USB volume looks like the same event, and analysts cannot tell routine work from replication. Start by building an allowlist of approved media and hosts before tuning any rule. Ask the endpoint team for the device classes in use, the owners of the approved drives (ideally identified by serial number or vendor and product ID), and the hosts where removable storage is a business need, such as kiosks, lab machines or imaging stations. Record the exceptions with an owner and a review date so the list does not drift.
The allowlist is what turns raw File Creation and Process Creation telemetry into a usable signal. When a Windows host writes an executable or script to a removable volume, the detection should check whether the drive and host pair is on the approved list, whether the account is one that normally handles that media, and whether the activity happens outside the hours or workflows the business expects. Events that match an approved pair can be suppressed or routed to a low-priority queue, while unknown drives on hosts that have no media need should raise an alert. Confirm with your own endpoint management and SIEM teams which device identifiers your telemetry actually records, because not every agent exposes serial numbers or vendor identifiers in the same field. Treat this as an illustrative tuning cycle: review suppressed events monthly and confirm the list still matches current hardware.
Media context also tells you where data may leave the environment. Map which approved hosts can write to removable storage and which of those hosts sit in segments that hold regulated or sensitive data. That map helps you decide which alerts need immediate response and which need a documented business justification. It also gives compliance and audit teams evidence that removable media is controlled by named owners, not by default. Confirm with your own asset inventory, data classification and endpoint policy owners what is covered today, because a baseline built from assumptions will fail the first time a new device class appears.
Preventive controls that reduce T1091 exposure
Most T1091 activity depends on a removable drive being accepted, opened and executed by an endpoint. The cards below cover the controls that remove or limit those steps: storage restrictions, endpoint behavior rules and the audit trail for exceptions. Each one has to be confirmed against the client's own endpoint platform and policy set before it is relied upon.
Restrict removable storage features
ATT&CK maps Disable or Remove Feature or Program (M1042) to this technique. In practice, this means turning off or narrowing the ability of endpoints to mount USB mass storage, optical media and similar devices where the business does not need them. Confirm the exact setting names and the device classes they cover in your endpoint management platform, and test the policy on a pilot group before broad rollout, since some peripherals share the same device classes.
Allowlist approved devices
Where removable storage must remain available, a device allowlist limits use to specific hardware identifiers issued or approved by IT. This makes a drive picked up from a parking lot or a conference unusable by default. Ask the platform team how device identifiers are collected, how new devices are added through a ticketed request, and whether the allowlist is enforced for both file transfer and autorun behavior.
Behavior prevention on endpoint
ATT&CK maps Behavior Prevention on Endpoint to this technique. Endpoint protection products can block or alert when a newly mounted volume launches executables, scripts or installers, or when a process spawned from removable media writes to system locations. Confirm which behaviors your product can observe and whether it can block them in prevention mode, not only log them, because some products offer detection without blocking.
Limit autorun and script execution
Autorun-style launch of content from newly attached media is a common pivot point for this technique. Group policy or endpoint configuration can disable automatic launch for removable volumes and restrict which script hosts can run from them. Verify the setting on each Windows build in the estate, because legacy images and specialist hosts such as kiosks or lab machines often carry older defaults.
Track exceptions with audit
ATT&CK maps Audit (M1047) as the way to keep the preventive controls honest. Every exception that permits a device class, a user group or a specific drive should be recorded with an owner, a business reason and an expiry date, and reviewed on a fixed cycle. Ask for the exception register format, the review cadence and the evidence that a removed exception was actually reverted on the endpoints.
Triage and response when a removable media alert fires
The first decision is whether the alert describes an approved drive doing approved work or an unknown drive doing something it should not. Start by confirming the host and the drive identity from the endpoint record: the hostname, the logged-on user at the time, the USB device serial number, vendor and product identifiers, and the volume label recorded when the device was mounted. Then check the drive against your asset register or device control allow list. If the serial number is unknown and the user cannot produce a business reason for connecting it, treat the alert as suspicious until proven otherwise. Do not run anything from the drive to investigate it. Work from the logs and from the host's own records of what was executed, created or read.
If the evidence shows malicious execution, such as an unexpected executable launched from the removable volume or a script that wrote persistence to the host, isolate the endpoint using your EDR or network containment process before further analysis. Preserve volatile data where your playbook requires it, and collect artifacts for analysis: the relevant event logs, prefetch and registry records of device use, the file hashes and copies of suspicious binaries, and the Wazuh or Security Onion alert and raw event context. Then search for other hosts that accessed the same device serial number or the same file hashes, since a single drive often moves between machines. Confirm the search window with your telemetry retention settings, because the earliest connection may fall outside what is still stored. Record every step, who performed it, and where each copy of evidence is held, so that chain of custody can be shown later.
Coordinate the response with your incident response plan from the start rather than improvising it on the day. Confirm which severity level applies, who can authorize isolation of a production system, and when the security operations lead must escalate. If the drive belonged to an employee, a contractor or a customer, involve legal counsel before any personal device is seized or examined, and involve HR where a policy breach is suspected. Ask your legal team which evidence handling standard applies in your jurisdiction and whether your regulators require notification. After closure, feed the findings back into your device control allow list and detection tuning, and confirm with your team which steps were slowed by missing logs or unclear ownership of the device.
Rehearsing T1091 detection in a private cyber range
A private cyber range for T1091 should mirror the endpoint and logging path your organization actually uses, without touching production systems or real removable media. The core build is a set of Windows endpoints with Sysmon installed and configured to record process creation and file creation events, forwarded to a Wazuh or Security Onion stack. Virtual removable media, such as mounted disk images presented as USB volumes, lets the team exercise the same mount and file write behavior without handling physical devices.
- Windows endpoints: Build a small set of clients that match your standard image, including the group policy and endpoint agent settings in use.
- Sysmon configuration: Use a documented configuration file so the range records the same event types your production estate is expected to record.
- Log pipeline: Confirm that Wazuh or Security Onion receives the events and that timestamps and host names are consistent.
- Virtual removable media: Use disk images with distinct volume labels so approved and unapproved media can be told apart in the data.
- Isolation: Keep the range on its own network segment with no route to production.
Before the first exercise, confirm in writing which Sysmon event types, Wazuh decoders and Security Onion data sources are in scope, and record the ATT&CK version the detections target.
Injects are scripted, benign replication events that the team runs on purpose so that detections can be measured against known input. The script should mount approved and unapproved virtual media at staggered times, copy and open benign sample files, and unmount them, so the rule must distinguish media by its registered identity and not only by the act of copying. Staggering the events shows whether correlation windows and alert thresholds behave as designed when activity is spread over time.
- Approved media: Mount a registered volume and perform routine file writes that should match the expected baseline.
- Unapproved media: Mount an unregistered volume and perform the same class of writes so the rule has a true positive to find.
- Staggered timing: Spread events over several intervals to test thresholds and time-window logic.
- Repeat runs: Run the same script more than once to check whether results are stable.
- Recorded ground truth: Keep a timed log of every inject so detections can be matched to what actually happened.
Before running injects, confirm with the range owner that all samples are benign, that no real malware or exploit code is used, and that the inject log is retained with the exercise record.
A good result is more than an alert appearing in the dashboard. The rule should fire for the unapproved media inject, the alert should carry enough context for an analyst to identify the host, user, device and time, and the analyst should triage it within the timing set in the agreed runbook. After triage, the team should tune the rule so that the approved-media baseline stays quiet without suppressing the unapproved case.
- Alert firing: The unapproved inject produces an alert in Wazuh or Security Onion, and the approved inject does not.
- Triage within runbook: The analyst follows the documented steps and records the decision and timestamps.
- Context present: The alert names the endpoint, account, device identifier and related process or file events.
- Tuned rule: The team adjusts the logic, for example by refining the device allow list, and reruns the injects to confirm the result.
- Documented outcome: Each change is versioned and linked to the exercise record.
Before accepting the result, check that the rule still maps to the ATT&CK version you target and that the mitigations Disable or Remove Feature or Program and Behavior Prevention on Endpoint are reflected in your control set.
Most first rehearsals reveal gaps, and those gaps are the most useful output of the exercise. Typical findings include telemetry that was never collected, rules that fire on legitimate administrative activity, and handoffs to incident response that are slower or less clear than the runbook assumes. Recording each gap with an owner and a retest date turns the exercise into an improvement plan rather than a one-off demonstration.
- Missing telemetry: File creation or device mount events are absent because a Sysmon rule or agent setting excludes them.
- False positives: Maintenance scripts, backup tools or legitimate new devices trigger the rule and bury real alerts.
- Slow triage: Analysts lack access to the device inventory needed to classify media.
- Handoff delays: Incident response is not engaged within the runbook timing, or the ticket lacks evidence fields.
- Retention limits: Relevant events age out before the exercise review.
Before closing the exercise, confirm which gaps are tracked, who owns each fix, and how the retest will prove the change worked in the same range.
Questions SOC leads ask about T1091 detection
Which Sysmon or Windows events do we need to detect removable media replication?
Start with process creation events, which show what launched from a removable drive, and file creation events, which show files written to removable volumes. Process creation and file creation are the two data components most useful for T1091 on Windows, and they should be collected with the executable path, parent process and drive letter or volume context intact. Confirm that your Sysmon configuration and Windows audit policy actually emit these events on your fleet before you write any rule, because a rule against missing telemetry will simply never fire.
How do we tune removable media rules without blinding the business?
Tune by asset group and by user role rather than switching detection off for a whole department. Build an allowlist of approved encrypted or managed devices, scope exceptions to named hosts with an owner and an expiry date, and review the exceptions with the business on a fixed cadence. Keep high-severity alerts for executable content launched from removable media, since that is the behavior that matters most for T1091, and route lower-severity file write events into a dashboard for trend review.
How can we test the detection without using real malware?
Use a benign, clearly labeled test binary on a virtual removable drive in a private cyber range, then confirm that the expected process creation and file creation events reach your SIEM with the right fields. Test the negative cases too, such as a normal document copy to a managed USB device, so you know what should stay quiet. Document each test with its ATT&CK version, the expected alert and the observed result, and rerun the tests after every change to the Sysmon configuration or detection logic.
How do we map our removable media detections to ATT&CK 20.0 IDs?
Map each rule to the technique ID T1091 and record the ATT&CK version you targeted, which for these pages is Enterprise ATT&CK 20.0. Check the technique page and its detection strategy for the data components it references, because ATT&CK v18 replaced technique-level detections with detection strategies and analytics. Re-check the mapping after each ATT&CK release, since releases can rename, deprecate or revoke techniques, and store the mapping in your detection-as-code repository so changes are reviewed.
How should we handle alerts from backup, imaging or asset management tools?
Treat these tools as known processes with their own signatures rather than as suspicious activity. Identify the service accounts, executable paths and hosts they use, then add scoped exclusions that match all three, so a rule still fires if an unexpected process runs under the same account from a different path. Review exclusions when backup or imaging software is upgraded, because a new binary path can quietly break an exclusion or widen it.
Can our own team run this detection, or do we need outside help?
Many SOC teams can run this detection in-house if they already operate Sysmon, a SIEM and a detection-as-code workflow, and the main work is tuning and testing. Where the gaps are telemetry coverage, rule maintenance or a lack of a safe test environment, a fixed-scope engagement can cover those specific items in writing. DeployOpen implements and documents self-hosted open-source platforms, runs security testing and operates private cyber ranges, so scope should be agreed in writing before work begins.
Does disabling removable media entirely reduce the need for detection?
Disabling or restricting removable media through policy reduces exposure, and ATT&CK lists Disable or Remove Feature or Program as a mitigation for this area. However, most organizations need some controlled device use, and policies are not always enforced on every endpoint, so detection still provides coverage for exceptions and gaps. Confirm which endpoints actually enforce the policy, then monitor the ones that do not and the approved exceptions.
How DeployOpen builds T1091 detections and range exercises
DeployOpen plans T1091 work as fixed-scope engagements, and the first step is confirming whether the client's Windows endpoints actually produce the telemetry a removable media detection depends on. In practice that means checking that Process Creation events are logged with command line and parent process, that File Creation events are captured for the drive letters and paths where removable media is mounted, and that File Access auditing is enabled only on the locations that matter, so the log volume stays manageable. The result is a written coverage map that names each data source, the hosts it covers, the gaps found, and the owner of each fix. The client's environment and the signed scope set the boundaries of this work, including which endpoint groups, which SIEM or Wazuh deployment, and which ATT&CK version the mapping targets.
Rule writing follows the coverage map. DeployOpen drafts open-source detection content, typically Sigma rules converted for the client's SIEM, and tunes it against the client's own baseline. Expect tuning around legitimate uses such as approved device encryption tools, backup utilities and asset management agents, and decide in advance which exceptions require a documented business owner. Each rule is recorded with its ATT&CK technique and sub-technique mapping, the ATT&CK version it was written against, and the data components it relies on. Because ATT&CK releases can rename or revoke content, the version recorded in each mapping is what allows a later reviewer to see why a rule exists.
Validation happens in a private cyber range, where purple team exercises replay removable media activity against cloned endpoints so the team can confirm that the rules fire, that alerts reach the right queue, and that responders can work through the case. Results are documented as a test record: what was run, what was detected, what was missed, and what changed. DeployOpen prepares this evidence for the client's own assessors, but it does not issue audit reports, attestations or certifications. Ask any partner, including DeployOpen, to state in the written scope which evidence will be delivered and which decisions remain with the client and its auditor.
