Physical & HID Attack Testing

Every post in this series so far has assumed an attacker sitting somewhere on a network — over Wi-Fi, over the internet, inside an AD domain. But there's a category of testing that skips the network stack entirely: what happens when an attacker can physically touch a badge reader, a door, or a USB port?

Physical security is often the most under-tested control in an organization, precisely because it feels separate from "cybersecurity." But a laptop with full-disk encryption and a hardened EDR agent means very little if someone can walk in the front door behind an employee and plug a malicious device directly into an unlocked workstation.

What Physical & HID Attack Testing Is

This category of VAPT assesses the physical controls protecting a facility and the hardware-based attack vectors that become available once physical proximity is achieved. It covers two related but distinct concerns:

• Access controls — can an unauthorized person get into a building or restricted area? (Tailgating, lock picking, badge cloning.)
• Hardware-based injection — once inside, can a device be used to compromise a system directly, bypassing network-layer defenses entirely? (HID injection via tools like the USB Rubber Ducky.)

Why It Matters

Physical access has historically been treated as a separate discipline from "real" penetration testing, but it deserves equal weight for one simple reason: physical access bypasses most digital controls entirely.

• Firewalls, EDR, and network segmentation all assume an attacker is coming in through the network. A device plugged directly into a USB port sidesteps every one of those layers.
• Badge systems and door locks are often managed by facilities teams, not security teams — creating a governance gap where nobody is explicitly responsible for testing them.
• Social pressure is a powerful bypass. Most people will hold a door for someone carrying boxes or wearing a lanyard that looks official, regardless of how strong the technical controls are behind that door.

Subtopic 1: Tailgating

Tailgating (or "piggybacking") is the practice of following an authorized person through a secured door without presenting your own credentials. It's the lowest-tech attack in this entire post and often the most effective, because it exploits social norms rather than any technical weakness.

Common pretexts used during authorized physical assessments:

• Carrying a box or equipment that makes holding a door "helpful" rather than suspicious.
• Wearing clothing or a badge that visually matches an expected role (delivery, maintenance, IT support).
• Simply walking confidently and close behind an employee at a badge-controlled door.

Defensive takeaway: Mantraps (single-person airlock doors) are the strongest technical control, but they're expensive and disruptive. A cheaper, high-impact control is a culture of polite confrontation — training employees that it's normal and expected to ask an unfamiliar person for their badge, and that doing so isn't rude.

Subtopic 2: Lock Picking

Lock picking during a physical assessment evaluates whether mechanical locks protecting server rooms, network closets, or restricted areas can be bypassed without a key or valid badge. Most commercial pin-tumbler locks can be manipulated using a tension wrench and a pick to individually set each pin to the shear line.

This is generally the slowest, most skill-intensive method in a physical assessment kit, and testers typically attempt it only after tailgating and social engineering approaches have been exhausted, since it requires close, extended, unobserved access to the lock itself.

Defensive takeaway: High-security cores (resistant to picking and bumping), combined with electronic access control logging every entry, close this gap far more effectively than upgrading to a "harder" mechanical lock alone. Any door protecting sensitive infrastructure should log entry attempts regardless of lock type.

Subtopic 3: Badge Cloning

Many organizations still rely on RFID/NFC proximity badges using older, weaker protocols (such as low-frequency 125kHz cards) that transmit a static, unencrypted identifier. If that identifier can be read, it can be duplicated onto a blank badge, granting the same access as the original — without the original ever leaving the employee's possession.

The general assessment flow:

1. Get a badge reader/cloner within range of a target's badge — often via brief, incidental proximity (a crowded elevator, a handshake with a badge in a shirt pocket).
2. Capture the transmitted card ID.
3. Write the captured ID to a blank clonable badge.

Defensive takeaway: Migrate to modern, encrypted credential systems (e.g., MIFARE DESFire or similar) that use cryptographic challenge-response instead of transmitting a static ID. Pair this with anomaly detection on badge systems — flagging the same badge ID used at two geographically distant readers within an implausible timeframe.

Subtopic 4: HID Injection

Human Interface Device (HID) injection abuses a fundamental trust assumption in modern operating systems: keyboards are trusted implicitly. Any device that identifies itself as a keyboard to the OS can send keystrokes, and the OS has no built-in way to distinguish a human typing from a malicious device typing on its own.

This is what makes HID injection so effective as an attack vector — it doesn't exploit a software vulnerability at all. It exploits the fact that keyboard input is, by design, unauthenticated and trusted.

Defensive takeaway: Endpoint controls that restrict or alert on unrecognized USB HID devices (via USB device control policies) are the most direct mitigation. Disabling autorun and enforcing a locked workstation policy also reduces the window in which a plugged-in device can act.

Subtopic 5: USB Rubber Ducky and DuckyScript

The USB Rubber Ducky is a purpose-built HID injection tool that looks like an ordinary USB flash drive but identifies itself to the host OS as a keyboard. Once plugged in, it types a pre-programmed sequence of keystrokes at machine speed — often completing an entire payload in under a second, far faster than any human could type or react.

DuckyScript is the scripting language used to author these payloads. Modern DuckyScript (version 3.0) supports variables, functions, conditionals, and loops, making it closer to a real scripting language than the simple keystroke-sequence format of earlier versions.

A conceptual (non-functional, illustrative) example of DuckyScript structure:

REM Example DuckyScript structure — illustrative only
DELAY 1000
GUI r
DELAY 500
STRINGLN notepad
DELAY 500
STRINGLN This is an example of HID-injected text.

REM Example DuckyScript structure — illustrative only
DELAY 1000
GUI r
DELAY 500
STRINGLN notepad
DELAY 500
STRINGLN This is an example of HID-injected text.

The payload above is intentionally trivial — it opens Notepad and types a benign line of text. The structural point is what matters for assessment purposes: DELAY statements wait for the OS to catch up, GUI r simulates a Windows-key shortcut, and STRINGLN types a line of text followed by Enter. Real payloads chain many such steps together, but the specific payload logic used in an actual engagement is scoped, authorized, and documented separately in the engagement's rules of engagement — not something to reproduce outside that scope.

Why it matters for testing: A successful HID injection demonstration proves that an unlocked, unattended workstation — even one with strong network-layer defenses — can be compromised in seconds by anyone with brief physical access, no credentials, and no network connection required.

Defensive takeaway: Enforce automatic screen lock on a short timeout, disable USB HID enumeration at the BIOS/UEFI level for kiosks or shared machines where feasible, and deploy endpoint agents capable of detecting anomalously fast keystroke injection patterns (a well-documented behavioral signature that distinguishes machine-typed HID input from human typing).

MITRE ATT&CK Mapping

(Cross-check exact sub-technique wording against the current ATT&CK Enterprise matrix at time of publishing.)

Blue Team Tie-In: Wazuh and Detection Opportunities

Physical and HID attacks are notoriously hard to detect purely from network telemetry, since by design they either happen off the network entirely (badge cloning, tailgating) or execute before any network connection is made (HID injection). Detection has to shift toward endpoint and physical-system logs:

• USB device event logging: Forward Windows Event ID 20001/20003 (or equivalent Sysmon device events) into Wazuh, and alert on new HID-class device enumeration on endpoints where no removable storage should ever appear.
• Keystroke velocity anomalies: Some EDR/Sysmon configurations can flag abnormally fast, uninterrupted keystroke bursts — a strong HID injection indicator, since no human sustains that typing speed with zero pauses.
• Badge system log correlation: Ingest access-control system logs into Wazuh as a custom log source, and alert on the same badge ID being used at two entry points that are physically impossible to reach within the elapsed time — a classic clone indicator.
• Physical + digital correlation: The highest-value detection is often correlating a badge entry log with a subsequent login event from that same employee's workstation — a mismatch (badge access recorded, but the employee is confirmed elsewhere) is a strong signal worth a dedicated Wazuh rule.

This post is part of an ongoing personal learning series on the VAPT lifecycle. Previous parts covered reconnaissance, scanning/enumeration, Active Directory attacks, web application testing, social engineering, post-exploitation/lateral movement, and wireless network testing — linked in my profile.