Live Active security incident? Get immediate response
MITRE ATT&CK® Analytic

AN0186: Analytic 0186

Chain: (1) udev / kernel logs show hot-plug (USB/Thunderbolt/PCIe); (2) block device created by udisks/diskarbitration; (3) optional: new network interface or DHCP lease observed. Correlate /var/log/messages|syslog, auditd SYSCALL open/creat on /dev, and DHCP/Zeek.

EnterpriseAN0186AnalyticObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

This analytic is about recognizing when new hardware or device-backed access appears on a Linux system by correlating hot-plug logs, block device creation, and optional network evidence. For leaders, the value is not just detecting a USB or Thunderbolt event; it is confirming whether the organization can reconstruct device-driven access paths that may affect data handling, incident scoping, and physical-to-cyber risk decisions.

Executive priority

Prioritize this where Linux systems are operationally sensitive, physically accessible, or part of regulated workflows requiring evidence of removable media or peripheral activity. The key management question is whether SOC and IR teams can prove when a new device appeared, whether it created storage or network capability, and which host evidence would support containment, audit, or investigation decisions.

Technical view

For Linux coverage, validate correlation across three evidence points from the supplied analytic: udev or kernel logs showing USB, Thunderbolt, or PCIe hot-plug activity; block device creation through udisks or related device-management logging; and, when applicable, a new network interface or DHCP lease observed through DHCP logs or Zeek. Also validate whether auditd captures SYSCALL open/creat activity against /dev paths. Because no ATT&CK tactic or relationship context is supplied, treat this as a detection analytic for device-introduction evidence rather than tying it to a specific intrusion phase without local investigation context.

Likely telemetry

  • Linux /var/log/messages or syslog entries for udev and kernel hot-plug events
  • udisks or device-management logs showing block device creation
  • auditd SYSCALL open/creat events involving /dev paths
  • DHCP server logs for new leases associated with newly observed interfaces
  • Zeek network telemetry for new interface or DHCP activity where deployed

Detection direction

  • Confirm that Linux endpoint logging actually records udev and kernel hot-plug events with sufficient host and timestamp fidelity.
  • Test whether block device creation events are visible and can be correlated to the same host and time window as hot-plug events.
  • Validate auditd rules and retention for open/creat activity on /dev paths; absence of auditd data may materially limit this analytic.
  • Use DHCP or Zeek context only as supporting evidence when a new network interface or lease is relevant; not every device insertion will produce network telemetry.
  • Tune expected administrative, maintenance, backup, and lab-device activity to reduce false positives while preserving investigation visibility for unusual hosts, times, or device types.

Mitigation priorities

  • Establish policy and asset expectations for peripheral and removable-device use on Linux systems before relying on alerting alone.
  • Ensure centralized collection and retention of Linux syslog/messages, udev/kernel evidence, auditd records, and relevant network logs.
  • Prioritize stronger monitoring on physically exposed, high-value, or operationally critical Linux hosts.
  • Use incident response procedures that preserve host logs and network lease evidence quickly, since these sources may roll over or be overwritten.
  • Where business risk warrants, pair detection with preventive controls for removable media, peripheral access, and physical access governance.
Analyst notes and limits

The supplied ATT&CK object is a detection analytic, AN0186, with Linux as the supported platform and no tactic or relationship context supplied. The official description provides the correlation chain but no separate official detection text. The mention of diskarbitration appears in the source description, but the platform field only supports Linux, so Linux telemetry should be the primary validation focus.

This take is limited to the supplied STIX fields, external reference, and absence of relationships. It does not establish adversary use, impact, attribution, or guaranteed detection. Local logging configuration, auditd policy, DHCP/Zeek deployment, physical access model, and approved peripheral workflows are required to determine actual coverage and risk.

Official MITRE ATT&CK definition

Analytic 0186

Chain: (1) udev / kernel logs show hot-plug (USB/Thunderbolt/PCIe); (2) block device created by udisks/diskarbitration; (3) optional: new network interface or DHCP lease observed. Correlate /var/log/messages|syslog, auditd SYSCALL open/creat on /dev, and DHCP/Zeek.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

Change history

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 .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
8179287c6f223049...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 8179287c6f22…
Raw source

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.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack AN0186
    Open source URL
Source and licensing

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.