AN0447: Analytic 0447
Insertion of USB-based hardware proxies (e.g., PiKVM) which register under predictable names (e.g., tinypilot) or mount under known paths (e.g., /opt/tinypilot-privileged).
Analyst context for executives and security teams
AN0447 highlights a Linux-focused detection idea for identifying USB-based hardware proxy devices, such as PiKVM-style tools, that may appear with predictable device names or install/mount paths. For leaders, the significance is that this behavior can indicate hands-on or near-hands-on access to infrastructure, potentially bypassing normal remote access, identity, and endpoint control assumptions.
Executive priority
Prioritize this as a physical-access and endpoint-monitoring validation item for Linux systems that support critical operations, administration, labs, or sensitive environments. The business question is whether the organization can prove when unexpected USB hardware or known proxy-related paths appear on important Linux assets, and whether incident response procedures treat that as a possible physical/cyber convergence event.
Technical view
For SOC and IR teams, validate Linux visibility for USB device registration, device names, mount activity, and filesystem paths associated with known hardware proxy tooling, specifically predictable names such as tinypilot and paths such as /opt/tinypilot-privileged as supplied by ATT&CK. Because no official detection logic or tactic mapping is provided, teams should treat this as a detection validation prompt rather than a complete analytic.
Likely telemetry
- Linux system logs related to USB device insertion and enumeration
- Kernel or udev events showing newly registered hardware
- Filesystem and mount telemetry for new or unusual paths
- Endpoint file creation or directory monitoring for paths such as /opt/tinypilot-privileged
- Asset inventory or hardware inventory records for approved USB devices on Linux systems
Detection direction
- Confirm whether Linux hosts collect and retain USB enumeration and mount evidence at a level useful for investigation.
- Create or validate alerts for unexpected USB hardware proxy indicators, including predictable names such as tinypilot and known paths such as /opt/tinypilot-privileged.
- Tune detections against approved lab, remote-support, or maintenance use to reduce false positives without suppressing visibility on critical systems.
- Correlate endpoint telemetry with physical access logs, maintenance windows, and asset ownership before escalating.
- Pay attention to blind spots on headless servers, appliances, isolated systems, or Linux hosts not enrolled in endpoint monitoring.
Mitigation priorities
- Define where USB-based remote management hardware is authorized and document exceptions.
- Restrict physical access to sensitive Linux systems and require change records for attached management devices.
- Harden Linux endpoint monitoring to capture USB device, mount, and filesystem events relevant to this behavior.
- Use asset and hardware inventory controls to distinguish approved devices from unexpected additions.
- Include suspected unauthorized hardware proxy insertion in incident response playbooks, including preservation of endpoint and physical-access evidence.
Analyst notes and limits
This object is a detection analytic, not a full ATT&CK technique description. It provides Linux as the platform and gives examples of predictable names and paths, but no official detection logic, tactic, relationship context, or mitigation mapping. Local baselining is essential because similar hardware or paths may be legitimate in support, lab, or remote administration workflows.
The supplied ATT&CK fields do not establish active exploitation, adversary attribution, impact, prevalence, or guaranteed detectability. No relationships were supplied, so this take cannot infer related techniques, groups, campaigns, or software.
Analytic 0447
Insertion of USB-based hardware proxies (e.g., PiKVM) which register under predictable names (e.g., tinypilot) or mount under known paths (e.g., /opt/tinypilot-privileged).
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 838e073fed92… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN0447Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.