THREAT-USB-AirGapBridging Elastic Security · Elastic

Detect Air-Gap Bridging Exfiltration via Shared USB Media in Elastic Security

Adversaries targeting air-gapped or network-segmented environments (ICS/OT, classified enclaves, isolated research networks) cannot rely on a network-based C2 channel to move stolen data off the isolated segment. Instead, malware families such as Agent.btz (the 2008 'Buckshot Yankee' incident), APT28's USBStealer, Machete, and Tropic Trooper's USBferry write themselves and staged data to removable media, then rely on a human or an automated routine to carry that same physical device to a network-connected host where the data is uploaded to the adversary. The defining artifact of this technique is not a single suspicious file, but a single USB device — identifiable by its device serial number — appearing on two or more hosts within a short window, especially when at least one of those hosts sits in an isolated or restricted network segment. A secondary artifact is the drop of a hidden collector/beacon file at the removable volume's root, historically a file literally named thumb.dd in the Agent.btz case, or an autorun.inf-based launcher in older variants.

MITRE ATT&CK

Tactic
Exfiltration

Elastic Detection Query

Elastic Security (Elastic)
eql
file where event.type == "creation" and
  file.name : ("thumb.dd", "autorun.inf") and
  file.path : ("D:\\*", "E:\\*", "F:\\*", "G:\\*") and
  not file.path : ("*\\*\\*")

/* Companion rule (run separately, requires host-correlation post-processing):
   any where event.category == "driver" and event.action == "device-connected" and
   device.type == "USB" */
high severity medium confidence

Detects the hidden collector artifact (thumb.dd, autorun.inf) written directly at a removable volume root — the primary on-device IOC for Agent.btz-family air-gap bridging malware. The companion PnP device-connection rule (commented) should be correlated post-hoc across hosts by device serial number to identify the same physical media appearing in multiple locations.

Data Sources

Elastic Endpoint SecurityElastic Agent (Endpoint Integration)

Required Tables

logs-endpoint.events.file-*

False Positives & Tuning

  • Legacy hardware installer media that legitimately ships an autorun.inf file
  • IT imaging or patch-deployment USB drives reused across multiple hosts as part of documented maintenance

Other platforms for THREAT-USB-AirGapBridging


Testing Methodology

Validate this detection against 2 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Simulate Hidden Collector Artifact Drop at Removable Volume Root

    Expected signal: Sysmon Event ID 11: File Create for '<DriveLetter>:\thumb.dd' at the volume root. Sysmon Event ID 2 (if configured) or file attribute change events for the subsequent hidden/system attribute application.

  2. Test 2Simulate Same USB Serial Connecting to Multiple Hosts

    Expected signal: DeviceEvents ActionType=PnpDeviceConnected on both Host A and Host B with an AdditionalFields.DeviceId sharing the same terminal serial-number segment.


Response Playbook

Triage

  1. Confirm the USB device serial number and pull its full connection history across the environment — how many distinct hosts has this exact device connected to, over what time span, and were any of those hosts in an isolated/restricted network segment (OT, classified enclave, R&D lab)?
  2. Check whether a hidden root-level artifact (thumb.dd, autorun.inf, or any dot-prefixed/hidden file) was written to the volume on any of the connecting hosts — this is the strongest single indicator of malicious intent versus benign shared-drive use.
  3. Review the file activity on each host around the time of connection: was a bulk copy of files performed to or from the device, and do those files match sensitive data categories (engineering drawings, PLC/HMI configuration, research data, financial records)?
  4. Identify who physically possessed the device between connections — badge/access logs, sign-out logs for shared IT hardware, or interviews if this appears to be an insider-carried device rather than automated malware propagation.
  5. Determine whether the device itself is infected: check for an autorun.inf or hidden executable on the media itself (requires physical or forensic imaging of the USB device) — if present, every host it touches going forward is at risk of re-infection.
  6. Cross-reference the affected hosts against your asset inventory for OT/ICS or air-gapped classification — a device that bridges a genuinely isolated segment to a network-connected host represents a completed air-gap breach, not just an in-progress one.

Containment

  1. Physically quarantine the USB device — do not reinsert it into any host until it has been forensically imaged; treat it as the primary vector for both malware propagation and data exfiltration.
  2. Isolate all hosts the device connected to, starting with any isolated/OT segment hosts, since those are least likely to have compensating network-based detections and most likely to represent the actual protected asset.
  3. If autorun.inf or a hidden collector artifact is confirmed on the device or any connected host, treat this as an active malware incident requiring full incident response, not a data-handling policy violation.
  4. Disable USB mass storage at the group policy or endpoint protection level for the affected network segment while the investigation is ongoing, if not already restricted (most true air-gapped/OT environments should default to disabled removable storage).
  5. Preserve the device and all connected hosts' relevant logs before any remediation actions that could overwrite volatile PnP/USB history.
  6. If exfiltration to a network-connected host is confirmed (i.e., the device later connected to an internet-reachable machine and data was uploaded), treat this as a completed exfiltration event and follow standard data-breach escalation.

Evidence Collection

  1. PnP device connection events (DeviceEvents PnpDeviceConnected, or Windows Security Event ID 6416) for every host the device serial number has touched, with timestamps
  2. Forensic image of the USB device itself — critical for identifying any hidden files, deleted-but-recoverable data, or an infected autorun component
  3. File system events (DeviceFileEvents, Sysmon Event ID 11) on each connected host for bulk copy operations to or from the removable drive letter in the time window around connection
  4. Any hidden or unusual files present at the volume root of the device: thumb.dd, autorun.inf, desktop.ini modifications, or unexpectedly named executables
  5. Physical chain-of-custody records for the device if it is IT-issued or logged out through an asset management system
  6. Network telemetry for the host where the device was last seen, to determine if and when collected data was subsequently uploaded off-premises — this is the actual exfiltration completion point when bridging from an isolated segment

Escalation Criteria

  • !The USB device connected to a host in a designated air-gapped, OT/ICS, or classified network segment and was subsequently seen on an internet-connected host — this is a confirmed air-gap bridging event, not a suspected one
  • !A hidden collector artifact (thumb.dd or equivalent) matching known Agent.btz/USBStealer/USBferry patterns was recovered from the device or a connected host
  • !The device shows connections across an unusually high number of distinct hosts (5+) in a short window, suggesting deliberate, systematic propagation rather than incidental reuse
  • !Sensitive OT/ICS engineering data, PLC configuration, or classified research data is confirmed present in file activity correlated with the device's connection window
  • !The device or its origin cannot be attributed to any known IT asset, employee, or contractor — an unidentified USB device bridging network segments is treated as a suspected deliberate intrusion tool pending attribution

Investigation Guide

Related Techniques

Forensic Artifacts

  • >Registry: HKLM\SYSTEM\CurrentControlSet\Enum\USBSTOR — persistent record of every USB mass storage device ever connected to a host, including the serial number, first-installed, and last-connected timestamps, even after the device is removed
  • >Registry: HKLM\SYSTEM\CurrentControlSet\Enum\USB — parent USB device enumeration entries correlating VID/PID to the mass-storage instance
  • >Event Log: Microsoft-Windows-DriverFrameworks-UserMode/Operational and Security Event ID 6416 — device installation events with serial number when 'Audit PNP Activity'/'Audit Removable Storage' policies are enabled
  • >File System: setupapi.dev.log (%WINDIR%\INF\setupapi.dev.log) — chronological driver installation log including every USB device's serial number and install timestamp
  • >File System: volume root of the removable device itself — thumb.dd, autorun.inf, or hidden system files are the primary on-device IOCs for Agent.btz-family malware
  • >LNK files / Jump Lists: Windows automatically creates shortcut files referencing recently accessed files on removable drives, which can reveal what was accessed even after the device is gone
  • >$MFT / USN Journal: NTFS journal entries on the host can reveal file creation/deletion on the removable volume's drive letter even if the device itself is unavailable for imaging

Tuning Guidance

The primary source of noise is IT-managed shared USB hardware: imaging drives, patch-deployment media, and backup rotation drives are expected to touch multiple hosts by design. Build an inventory reference list of approved shared-device serial numbers (extracted from HKLM\SYSTEM\CurrentControlSet\Enum\USBSTOR or your asset management system) and exclude them from the multi-host correlation, while still monitoring for the hidden-artifact signal against all devices including allowlisted ones — a compromised IT imaging drive is a realistic supply-chain-style propagation vector. In genuinely air-gapped or OT/ICS environments, the correct baseline is that removable storage should be disabled entirely (via Group Policy or endpoint DLP); in such environments, any PnpDeviceConnected event at all — regardless of serial-number correlation — should be treated as a policy violation worth investigating, and this detection's multi-host correlation becomes a secondary escalation signal rather than the primary trigger. Ensure the 'Audit PNP Activity' and 'Audit Removable Storage' Group Policy settings are enabled fleet-wide; many organizations do not log Security Event ID 6416 by default, which silently defeats the SPL detection's device-serial correlation.


Hunting Queries

Fleet-wide hunt for any USB mass storage device serial number that has connected to more than one distinct host over the last 90 days. In most enterprises this is uncommon for personally-owned drives; cross-reference results against your IT asset inventory to separate approved shared-use devices (imaging drives, backup rotation media) from unexplained multi-host devices.

Hunting — KQL
kql
DeviceEvents
| where Timestamp > ago(90d)
| where ActionType == "PnpDeviceConnected"
| where AdditionalFields has "USB"
| extend DeviceIdField = tostring(parse_json(AdditionalFields).DeviceId)
| extend USBSerial = tostring(split(DeviceIdField, "\\")[-1])
| where isnotempty(USBSerial) and USBSerial != "0"
| summarize HostCount = dcount(DeviceName), Hosts = make_set(DeviceName, 20),
    FirstSeen = min(Timestamp), LastSeen = max(Timestamp)
  by USBSerial
| where HostCount >= 2
| sort by HostCount desc
Hunting — SPL
spl
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" OR sourcetype="WinEventLog:Security" EventCode=6416
| stats dc(host) as HostCount, values(host) as Hosts, earliest(_time) as FirstSeen, latest(_time) as LastSeen by SerialNumber
| where HostCount >= 2
| sort - HostCount

Direct hunt for the known Agent.btz-family hidden artifact filenames (thumb.dd, autorun.inf) being written to a removable drive's volume root. Any hit on this query in a modern environment is high-confidence malicious activity, as these filenames have no legitimate enterprise use case.

Hunting — KQL
kql
DeviceFileEvents
| where Timestamp > ago(30d)
| where ActionType == "FileCreated"
| where FileName in~ ("thumb.dd", "autorun.inf")
| where FolderPath matches regex @"^[D-Z]:\\$"
| project Timestamp, DeviceName, FileName, FolderPath, InitiatingProcessFileName, InitiatingProcessCommandLine
| sort by Timestamp desc
Hunting — SPL
spl
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=11
(TargetFilename="D:\\thumb.dd" OR TargetFilename="E:\\thumb.dd" OR TargetFilename="F:\\thumb.dd"
 OR TargetFilename="D:\\autorun.inf" OR TargetFilename="E:\\autorun.inf" OR TargetFilename="F:\\autorun.inf")
| table _time, host, TargetFilename, Image
| sort - _time

Atomic Red Team Tests

Test 1 Simulate Hidden Collector Artifact Drop at Removable Volume Root
windows

Simulates the Agent.btz-family behavior of writing a hidden collector file named thumb.dd to the root of a removable volume. Uses a harmless placeholder file and a specified drive letter to avoid requiring an actual physical USB device — substitute a real removable drive letter to fully validate telemetry.

Command

powershell
set /p DriveLetter="Enter a removable drive letter for this test (e.g. E): "
echo harmless-atomic-test-payload > %DriveLetter%:\thumb.dd
attrib +h +s %DriveLetter%:\thumb.dd

Cleanup

powershell
del /a:h /f %DriveLetter%:\thumb.dd

Expected Telemetry

Sysmon Event ID 11: File Create for '<DriveLetter>:\thumb.dd' at the volume root. Sysmon Event ID 2 (if configured) or file attribute change events for the subsequent hidden/system attribute application.

Expected Detection

KQL HiddenDropperArtifact signal fires on FileName='thumb.dd' with FolderPath matching the drive-root regex. SPL EventCode=11 detection fires on the matching TargetFilename. This signal alone is high-confidence; pair with the multi-host PnP connection test below to validate the full correlated rule.

Test 2 Simulate Same USB Serial Connecting to Multiple Hosts
windows

This test cannot be fully automated on a single host, since it requires physically connecting one USB device to two or more distinct endpoints. Documented here as a manual validation procedure: connect the same USB mass storage device to Host A, then within the detection window connect it to Host B, and confirm both PnpDeviceConnected telemetry events share the same device serial number.

Command

powershell
# Manual procedure — not a single-host command:
# 1. Insert a test USB drive into Host A. Note the resulting DeviceEvents PnpDeviceConnected event and record its AdditionalFields.DeviceId.
# 2. Remove the drive and insert it into Host B within 72 hours.
# 3. Confirm both hosts' PnpDeviceConnected events resolve to the same USBSerial value when parsed via split(DeviceId, "\\")[-1].

Cleanup

powershell
# Remove the test USB device from both hosts after validation.

Expected Telemetry

DeviceEvents ActionType=PnpDeviceConnected on both Host A and Host B with an AdditionalFields.DeviceId sharing the same terminal serial-number segment.

Expected Detection

KQL SameSerialMultiHost signal fires with HostCount=2 for the shared USBSerial value, surfacing both ConnectedHosts.

Related Detections

Detection Variants (1)

Different telemetry and tradecraft for the same technique — pick the one that matches the data you collect.