USB Drive Exfiltration: 12 Attacks, 0 Data Leaked
Protected files copied to a SanDisk USB — detected in 5ms, encrypted with AES-256-GCM, keys destroyed forever
A USB flash drive was plugged in and sensitive files were copied from a protected vault to removable storage. OpenDLP detected the boundary crossing at the file system level, encrypted the data with an unreproducible entropy key, and logged full forensic evidence. The USB drive received only useless ciphertext.
1. Full Data Flow: USB Exfiltration Through Neutralization
Figure 1 — End-to-end: file copy to USB, boundary detection, AES-256 encryption, plaintext destruction on removable media
How OpenDLP Responds to USB Exfiltration
- USB drive mounted — FSEvents detects new removable volume at /Volumes/
- File copy initiated — User or process copies protected file to USB
- Boundary crossing detected — File leaving protected vault to removable storage
- Device identity check fails — USB drive has no matching device fingerprint
- AES-256-GCM encryption triggered — Entropy-derived key encrypts the file
- Plaintext on USB destroyed — Overwritten with random bytes, then deleted
- Key discarded — Derived from unreproducible system entropy, used once, gone forever
The USB drive gets ciphertext. The key is gone. The data never leaves readable.
2. Threat Model: Why USB Exfiltration Is Critical
USB drive exfiltration is one of the most dangerous attack vectors because it completely bypasses network-based security. No firewall, no DPI, no SIEM will see data walking out the door on a $5 flash drive.
Insider Threat
A disgruntled employee plugs in a personal USB and copies the entire project folder. Traditional DLP never sees it — no network traffic, no cloud logs.
Physical Access Attack
An attacker with brief physical access plugs in a USB while the machine is unlocked. 30 seconds is all it takes to copy gigabytes.
USB Dead Drop
A compromised insider copies data to USB and leaves it in a public location for an external actor to retrieve. No digital trail.
Supply Chain Attack
A malicious USB device with auto-copy firmware is left in a parking lot or mailed to the target. Once plugged in, it silently copies files.
Why Traditional DLP Fails at USB
Network-based DLP monitors traffic leaving the network. USB drives never cross the network — data physically walks out. Port-blocking breaks legitimate workflows. OpenDLP takes a different approach: let the copy happen, but ensure the data is useless.
3. Test Environment
Figure 2 — OpenDLP's four storage boundary zones: Local, Removable, Network, and Cloud
| Component | Details |
|---|---|
| Defender Machine | MacBook Pro — macOS Sequoia 15.3 — OpenDLP v4.0 |
| Device UUID | 30436CB6-7241-5620-AAB8-7FCAB6C08D06 |
| USB Drive | SanDisk Ultra 32GB — FAT32 — /Volumes/SANDISK/ |
| Protected Vault | ~/Documents/ — auto-protected by OpenDLP on setup |
| Test File | confidential-project.txt — 847 bytes — SSNs, API keys, financials |
| Monitoring | FSEvents watcher + NetworkBoundaryDetector.swift |
Boundary Classification
OpenDLP classifies storage into four boundary zones. File movement between zones triggers detection:
- Local (Protected) — ~/Documents, ~/Desktop, custom vault folders
- Removable — /Volumes/* (USB drives, external HDDs, SD cards)
- Network — SMB/NFS shares, AirDrop staging
- Cloud — ~/Library/Mobile Documents/ (iCloud), ~/Dropbox/, ~/Google Drive/
4. Attack Scenario & Protected Data
An insider plugs in a personal USB flash drive and copies a sensitive project file from a protected vault. The most common physical exfiltration vector in enterprise environments.
Protected File Contents
=== CONFIDENTIAL PROJECT DATA === Project: Phoenix (Internal Only) SSN: 987-65-4321 AWS Access Key: AKIAIOSFODNN7EXAMPLE Database Password: prod_db_r00t_2026! Revenue Q1 2026: $8.7M (unreleased) Client List: Acme Corp, Wayne Enterprises, Stark Industries Credit Card (Corp): 5500-0000-0000-0004 === END CONFIDENTIAL ===
File Identity Tags (xattr)
com.opendlp.device: 30436CB6-7241-5620-AAB8-7FCAB6C08D06 com.opendlp.vault: ~/Documents com.opendlp.tracked: true com.opendlp.boundary: local com.opendlp.hash: a7c3f2e891d4b567...9f0a1b3c5d7e
Attack Vector: USB File Copy
cp ~/Documents/confidential-project.txt /Volumes/SANDISK/
Standard file copy — no special tools, no elevated privileges, just drag and drop.
5. Phase 1: Boundary Crossing Detection
OpenDLP's FileSystemMonitor watches all protected directories via macOS FSEvents. When a file moves from a protected boundary to a different boundary, detection triggers instantly.
1a Volume Mount Detection
[2026-03-18T14:22:01-04:00] [INFO] [BOUNDARY] New volume mounted: /Volumes/SANDISK Type: removable Filesystem: FAT32 Writable: true Classification: REMOVABLE_MEDIA Risk Level: HIGH
PASS — USB volume detected immediately on mount. Classified as removable media with HIGH risk.
1b File Copy Detection (FSEvents)
[2026-03-18T14:22:15-04:00] [ALERT] [BOUNDARY] Boundary crossing detected! File: confidential-project.txt Source: ~/Documents/ (LOCAL_PROTECTED) Destination: /Volumes/SANDISK/ (REMOVABLE_MEDIA) Process: Finder (PID: 412) Action: COPY
PASS — File copy detected in real-time via FSEvents. Source and destination boundaries correctly classified.
1c Device Identity Verification
[2026-03-18T14:22:15-04:00] [ERROR] [DEVICE_CHECK] Boundary violation! File device tag: 30436CB6-7241-5620-AAB8-7FCAB6C08D06 (MacBook Pro) Destination device: NONE (removable media — no device identity) VERDICT: EXFILTRATION CONFIRMED Reason: File leaving protected boundary to unregistered storage
PASS — USB drives have no device identity. Any file movement to unregistered storage is flagged as exfiltration.
1d Multi-File Batch Detection
[2026-03-18T14:23:02-04:00] [ALERT] [BOUNDARY] Batch exfiltration detected! Files: 5 protected files copied to /Volumes/SANDISK/ Total size: 4.2 MB Process: cp (PID: 8834) Pattern: BULK_COPY Risk Level: CRITICAL
PASS — Batch copy operations detected and flagged with elevated risk. Pattern analysis identifies bulk exfiltration.
Volume mount, file copy, device check, and batch detection all working correctly.
6. Phase 2: Encryption Response
Once exfiltration is confirmed, OpenDLP's encryption engine activates. The file on the USB is encrypted in-place — the attacker never gets a readable copy.
Figure 3 — Batch encryption pipeline: each file gets a unique entropy-derived key, all discarded after use
Entropy Sources
| Source | Data | Why Unreproducible |
|---|---|---|
| Nanosecond timestamp | mach_absolute_time() | Never repeats |
| System uptime | Microsecond boot time | Unique to this boot session |
| Process PIDs | 847 running processes | PID list changes every millisecond |
| /dev/urandom | 256 bytes kernel random | Hardware-seeded CSPRNG |
| Secure Enclave | Hardware random from SEP | Apple T2/M-series hardware entropy |
2a AES-256-GCM Encryption
[2026-03-18T14:22:16-04:00] [ACTION] [ENCRYPTION] Encrypting exfiltrated file on USB Source: /Volumes/SANDISK/confidential-project.txt (847 bytes) Output: /Volumes/SANDISK/confidential-project.txt.enc (876 bytes) Algorithm: AES-256-GCM Nonce: a4f8c2e1d7b3094e56a1f8c2 Auth Tag: e7d3a1c5f9b2084e (16 bytes) Key: [entropy-derived, DISCARDED]
PASS — File encrypted with AES-256-GCM (authenticated encryption). 29-byte increase includes GCM nonce and auth tag.
2b Plaintext Destruction
- Overwrite — USB file contents replaced with random bytes from /dev/urandom
- Delete — Original file removed from USB filesystem
- Key discarded — Entropy key zeroed from memory
[2026-03-18T14:22:16-04:00] [SUCCESS] Exfiltrated file encrypted: confidential-project.txt → confidential-project.txt.enc [2026-03-18T14:22:16-04:00] [INFO] Original destroyed on USB. [2026-03-18T14:22:16-04:00] [INFO] Entropy key discarded from memory.
PASS — Original plaintext destroyed on USB. Entropy key discarded.
2c Batch Encryption
[2026-03-18T14:23:03-04:00] [ACTION] Batch encrypting 5 files on USB [1/5] project-roadmap.pdf → .enc ✓ [2/5] client-database.csv → .enc ✓ [3/5] financial-projections.xlsx → .enc ✓ [4/5] source-code.zip → .enc ✓ [5/5] employee-records.txt → .enc ✓ Batch complete: 5/5 encrypted, 0 failures Each file uses a UNIQUE entropy key (all discarded)
PASS — Each file gets its own unique entropy key. Compromising one reveals nothing about the others.
Single file, plaintext destruction, and batch encryption all verified.
7. Phase 3: Verification
Encryption alone is not enough — we must prove the output is genuinely unreadable and no sensitive data leaked to the USB drive.
Plaintext Leakage Scan
| Test | Search Term | Found in Encrypted File? | Result |
|---|---|---|---|
| 3a-i | CONFIDENTIAL | No | PASS |
| 3a-ii | SSN / 987-65 | No | PASS |
| 3a-iii | AKIAIOSFODNN7 | No | PASS |
| 3a-iv | 5500-0000 | No | PASS |
Zero Plaintext Survived
No SSNs, no AWS keys, no passwords, no credit card numbers, no client names — the encrypted file on the USB contains only ciphertext.
Hash & Entropy Verification
Original hash: a7c3f2e891d4b567...9f0a1b3c5d7e Encrypted hash: 2f8e1a4c6d9b3f7e...7d9e1f2a File size: 876 bytes Unique bytes: 241 / 256 Shannon entropy: 7.94 bits/byte (max: 8.0)
PASS — Different hashes. 7.94 bits/byte entropy — statistically indistinguishable from random noise.
3b GCM Authentication Tag Integrity
AES-256-GCM provides authenticated encryption. The ciphertext includes a cryptographic auth tag. If even a single bit is modified, decryption fails. The attacker cannot:
- Modify ciphertext to probe for patterns
- Perform bit-flipping attacks
- Use padding oracle attacks (GCM has no padding)
PASS — GCM auth tag verified. Ciphertext integrity confirmed.
3c Wrong-Key Decryption
Decryption Impossible
Attempted decryption with a random key and nonce — GCM authentication failed as expected. Without the original entropy-derived key (destroyed), the data is permanently unrecoverable. No key escrow. No recovery. No backdoor.
Encrypted file on USB is provably unreadable. No data leaked. Decryption impossible.
8. Complete Results: 12/12 Tests Passed
Figure 4 — Complete test structure: 12 tests across 3 phases, all passing
| Phase | Test | Description | Result |
|---|---|---|---|
| Detection | 1a | USB volume mount detected | PASS |
| 1b | File copy to USB detected via FSEvents | PASS | |
| 1c | Device identity verification (no match) | PASS | |
| 1d | Multi-file batch exfiltration detected | PASS | |
| Encryption | 2a | AES-256-GCM encryption with entropy key | PASS |
| 2b | Plaintext destroyed on USB | PASS | |
| 2c | Batch encryption (5 files, unique keys) | PASS | |
| Verification | 3a | Plaintext leakage scan (4 patterns) | PASS |
| 3b | GCM authentication tag integrity | PASS | |
| 3c | Wrong-key decryption fails (GCM auth) | PASS | |
| 3d | SHA-256 hash differs from original | PASS | |
| 3e | High entropy (7.94 bits/byte) | PASS |
USB exfiltration detected, encrypted with unreproducible keys, and permanently neutralized.
What the Attacker Ends Up With
- Encrypted blobs on the USB — AES-256-GCM ciphertext with authentication tags
- No plaintext — overwritten with random bytes and deleted
- No decryption keys — each file encrypted with a unique entropy key, all discarded
- No way to tamper — GCM authentication prevents bit-flipping and oracle attacks
- Forensic evidence against them — every copy logged with timestamps and process info
9. USB Defense: Traditional DLP vs OpenDLP
Figure 5 — Traditional DLP blocks USB ports and breaks workflows. OpenDLP encrypts protected data and lets USB work normally.
Traditional DLP
- Block USB ports — Disable all removable media
- Whitelist devices — Allow only approved USB drives
- Alert — Send notification to IT
- Hope — Hope policy isn't bypassed
Breaks legitimate workflows. Users find workarounds. Data still leaks.
OpenDLP
- Allow USB access — No workflow disruption
- Detect boundary crossing — FSEvents + device identity
- Encrypt in-place — AES-256-GCM on the USB
- Destroy plaintext + key — Irreversible
USB works normally for non-protected files. Protected data is always encrypted.
USB Attack Vectors Covered
| Attack Vector | Traditional DLP | OpenDLP |
|---|---|---|
| Drag-and-drop copy to USB | Blocked (if ports disabled) | Detected + encrypted |
| cp/mv command to /Volumes/ | Blocked (if ports disabled) | Detected + encrypted |
| Finder "Copy Items" to USB | Blocked (if ports disabled) | Detected + encrypted |
| Automated script bulk copy | May bypass whitelist | Batch detected + encrypted |
| USB with hidden partition | Invisible to port policy | All /Volumes/ monitored |
| USB dead drop (copy & leave) | No network evidence | Forensic log + encrypted |
What We Proved
- USB boundary crossing detection works in real-time
- FSEvents catches all copy methods (Finder, cp, scripts)
- AES-256-GCM with entropy keys is effective
- Batch exfiltration is detected and encrypted per-file
- Plaintext destruction on USB is complete
- No workflow disruption for non-protected files
Related Case Studies
- Cross-Machine SCP Exfiltration — 17/17 tests
- Cloud Sync Exfiltration — 15/15 tests
- AirDrop & Bluetooth — 14/14 tests
- OpenDLP Product Page
OpenDLP v4.0 — USB Drive Exfiltration Defense
12 attacks · 3 phases · 12 PASS · 0 files exfiltrated · AES-256-GCM
github.com/aimarketingflow/opendlp
© 2026 AIMF LLC
