How T1200 hardware additions get an attacker into the network
T1200 Hardware Additions is the technique where an adversary gets access by connecting a device of their choosing to a network or endpoint that the organization did not authorize. For a SOC lead, the first signal is often an unfamiliar device on a switch port, a Wi-Fi access point nobody registered, or a USB peripheral that appears on a workstation with no change record. This page targets MITRE ATT&CK Enterprise version 20.0, and the detection and mitigation mappings below should be checked against that version. ATT&CK defines the Initial Access tactic (TA0001) as follows: "The adversary is trying to get into your network." Hardware additions fit that goal because a device placed inside the perimeter can reach internal systems without passing through the controls that guard the internet edge.
In practice, the adversary introduces hardware that either carries out the intrusion itself or relays traffic for a later stage. The device may be a rogue network element plugged into a spare port, a wireless access point that bridges into a corporate segment, or a removable peripheral that presents itself to an operating system as something it is not. Because the device sits inside trusted address space, traffic it generates can look like normal internal activity. The decisions that matter most for the reader are which ports and wireless bands are physically reachable, whether a device must authenticate before it gets a network address, and whether endpoints restrict what a newly attached peripheral may do. Confirm these with your network and endpoint owners before you tune any detection, because they determine which telemetry will show an introduction at all.
Start by inventorying where a new device could enter: access switch ports in public or shared areas, meeting rooms, loading docks, and any wireless networks with weak or shared credentials. Then confirm which of those points already require device authentication or port security, and which rely only on physical controls. Record the gaps. The gap list becomes the scope for the detection work that follows, and it gives you a defensible answer when someone asks why a given port alert fired or did not fire.
Which telemetry reveals a hardware addition
This table maps the three data components named for this technique (Network Connection Creation, Process Creation and Application Log Content) to the signal each one can reveal, and the open-source collector that typically gathers it. Read each row as a starting point for the client's own log sources, then confirm coverage on each platform before relying on it. The main takeaway is that no single data component shows a hardware addition on its own, so correlation across host, network and authentication logs is what makes the detection useful.
| Telemetry | Signal to look for | Open-source collector to confirm |
|---|---|---|
| Network Connection Creation (DC0082), host side | New outbound or internal connections opened by a device management or driver process shortly after a device arrival event, from a host that did not previously use that path | Sysmon-based logging on Windows, auditd or Velociraptor on Linux and macOS, forwarded to Wazuh; confirm event coverage per endpoint |
| Network Connection Creation (DC0082), network side | A newly seen MAC address or DHCP lease bound to a wired or wireless port, or a device opening sessions to hosts outside its normal profile | Zeek connection and DHCP logs, Suricata flow events, within Security Onion; confirm sensor placement on the access segment |
| Process Creation (DC0032) | Unexpected interpreter, shell or installer processes started within a short window after a USB or peripheral device event, especially under a user session with no prior activity | Sysmon process creation events on Windows, auditd execve records on Linux, Velociraptor hunts for process trees; forwarded to Wazuh rules |
| Application Log Content (DC0038), authentication | New device or session logins, account activity from an unfamiliar workstation, or privilege changes logged near the time a device was attached | Wazuh collection of Windows Security, PAM and syslog authentication records; confirm log retention and time synchronization across sources |
| Application Log Content (DC0038), device and system | Kernel or plug-and-play messages recording a new device class, driver load or mount event, which show the addition itself | Wazuh log collection from journald, syslog or the Windows System log; confirm which device event IDs your platform logs by default |
| Correlation across all three | A single time-ordered view that joins a device event, the process tree it started, any new connection, and the authentication record for the same host | Wazuh and Security Onion dashboards with shared host and time keys; confirm that host names and clocks match across collectors |
Detection logic for hardware additions that SOC teams can tune
Hardware additions are hard to see because a new device often looks like ordinary onboarding. The four cards below pair each detection idea with the context that separates a rogue device from an approved one, so analysts can tune alerts without suppressing real activity. Write each idea as a Sigma rule first, then test it against your own asset inventory and change calendar.
New device on a segment
Alert when a device appears on a network segment where no device has been seen for that segment's expected population, or when the number of new hosts on a VLAN rises above its normal baseline during a period. Use Network Connection Creation (DC0082) telemetry to build the baseline per segment and per port. Tuning threshold: start with a single unknown host per segment per hour and widen only after two weeks of review. False positives come from IT asset onboarding, new laptop refresh cycles, and docking stations that bring a new MAC address into a desk VLAN. Check the change ticket before escalating.
First-seen MAC or device identifier
Flag a MAC address or device identifier that has never appeared in your asset inventory or DHCP history. The first-seen logic is simple, but it depends on a clean reference list. Use Application Log Content (DC0038) from DHCP and NAC platforms as the source, and keep the allow list in version control so changes are reviewed. Tuning tip: suppress known vendor OUI prefixes only for asset types you actually deploy. False positives include replacement network cards, virtual machine bridging, and MDM-enrolled phones connecting to guest networks.
Device activity outside change windows
Correlate new device events with your approved change calendar and alert when a device connects or changes state outside the window owned by IT operations. Pull change records from the ticketing system into the SIEM as a lookup table so the rule can match on time and asset owner. Tuning threshold: define one window per site and treat any connection outside it as a medium-severity event. False positives come from shift work, emergency repairs logged late, and vendor maintenance that was approved verbally. Confirm with your change manager which windows are authoritative.
Process or service creation after connection
Raise priority when a Process Creation (DC0032) event on a host starts a new service, driver, or script within a short window after a removable or new network device connects. This is the signal that most often separates a benign peripheral from a device that executes code. Tune the window to a few minutes and exclude known management agents by signed publisher and path. False positives include printer drivers, docking station firmware helpers, and endpoint agents that restart after a USB event. Review the rule against a lab device before it goes to production.
How to validate that the T1200 detection fires
This sequence proves that the T1200 Hardware Additions detections fire on Windows, Linux and macOS when a lab emulation introduces unapproved hardware, and it produces a dated record that shows which collector saw the event, which rule fired and how quickly the team triaged it. The same record becomes the baseline for repeating the test after rule or ATT&CK version changes.
Define the test hardware class and scope
The detection owner and the cyber range lead agree on the hardware class to emulate, such as an unapproved USB storage device or a network-attached peripheral, and on the endpoints in the range that will receive it. The test scope must stay inside the private range, with the device class, the host list and the approved change window written down before anything is connected. Done means a signed-off test card exists that names the ATT&CK version being validated, for example v20.0, so that results can be compared later. Ask the range provider to confirm which device classes the lab can represent safely.
Map expected telemetry for each platform
For each platform in scope, the team lists the telemetry that should appear when the test device is introduced, using the data components that ATT&CK links to the technique's detection strategies, such as Network Connection Creation, Process Creation and Application Log Content. Windows, Linux and macOS will not produce identical events, so the expected record differs per host type and per collector. Done means a table exists that states the source log, the field that should change and the rule ID expected to fire. Confirm the current detection strategy and analytic IDs in the ATT&CK version under test, since mappings can change between releases.
Set pass criteria and rule IDs under test
Before the emulation runs, the team writes pass criteria that a reviewer can check without interpretation. Examples include that the expected rule fires on every in-scope host type, that the alert reaches the case management queue within the response window the SOC has already defined, and that no alert is suppressed by an exclusion added for convenience. Each criterion is tied to a specific rule ID and a specific collector. Done means the test card lists the rule IDs, the collector for each platform and a pass or fail rule for each line.
Run the emulation and record the event trail
The range operator introduces the test hardware class on each in-scope host according to the test card, and a second person observes the console and logs without changing them. The operator records the start time, the host, the device class and the time the device was removed. The observer records what the collector received and when. Done means the raw events are preserved with their original timestamps and the operator's notes match the event times, so that clock skew between hosts and the SIEM can be checked before results are scored.
Capture alert evidence and triage timing
For every expected rule, the team captures the alert ID, the rule version, the collector that generated it, the timestamp of the first event, the timestamp of the alert and the timestamp when an analyst opened and classified it. Time to triage is the gap between alert creation and analyst classification, and the team reports it per platform so that a slow path on one operating system is visible. Done means a results sheet holds one row per host and rule, with no blank fields, and any missing alert is marked as a failure with the reason recorded.
Score results and log detection gaps
The reviewer compares the results sheet with the pass criteria and marks each line as passed, failed or partially met. Partial results, such as an alert that fires on Linux but lacks the device identifier needed for triage, become tracked gaps with an owner and a retest date agreed with the detection owner. Done means every gap has a ticket, every pass has the evidence attached and the report is stored with the test card and the ATT&CK version under test. Confirm with the team that the stored evidence meets the retention rules that apply to the environment.
Repeat the test after rule or version changes
The same test card is rerun after any change to a rule, a collector configuration, a logging policy, or the ATT&CK version that the detection targets. Because ATT&CK releases can rename, deprecate or revoke techniques, the team checks the technique page and its detection strategy for the new version before rerunning, and records the version in the new report. Done means the new results sit beside the previous ones, so that any regression in coverage is visible rather than assumed. Decide with the detection owner how often the test repeats for each platform and document that schedule.
Preventive controls that limit hardware additions
Two ATT&CK mitigations shape how far a newly attached device can go on a network or endpoint. The cards below separate network reach, port design, endpoint installation rules, approved device records and proof that the controls work in practice.
Restrict network reach for new devices
Limit Access to Resource Over Network limits which hosts and services a device can reach once it connects. For T1200 Hardware additions, the goal is that an unapproved device gets no path to internal systems until someone approves it. Confirm how your switches, wireless controllers and network access control tooling enforce port-level authentication and default-deny rules for unknown endpoints. Ask whether that enforcement is re-tested after each network change.
Review open physical ports
Physical ports in meeting rooms, lobbies, contractor areas and labs are the most common entry point for an added device. Map which ports are live, which VLAN each one lands on and whether any port bypasses authentication. Check that unused ports are disabled or placed in a quarantine segment with no route to internal services. Record the owner of each port so that a new device on it can be traced to a person and a change request.
Govern device installation on endpoints
Limit Hardware Installation restricts which device classes an endpoint will accept, such as removable storage, network adapters and human interface devices. Enforcement usually comes from Windows group policy, MDM profiles on macOS and Linux management tooling. Confirm that each operating system in your fleet has a policy, that policies cover the device classes your threat model names, and that exceptions go through a documented approval step.
Maintain an approved device register
An approved device register lists vendor and product identifiers, serial numbers, owners and approval dates for hardware that may connect. Endpoint and network controls use this list to build allowlists, so it must match what procurement actually buys. Review the register when vendors change or when a device is retired. Confirm the mitigation IDs for both controls against the T1200 entry in the ATT&CK 20.0 STIX bundle before you cite them in a control matrix.
Prove enforcement in the cyber range
A control that has never been tested is an assumption. In a private cyber range, an illustrative test plugs an unapproved test device into a quarantine port and records whether network access is denied, whether the endpoint policy blocks the device class and whether both events reach the SIEM. Repeat the test after each change to switches, endpoint policy or the device register. Keep the results as evidence for your assessment.
Triage and response when a hardware addition alert fires
The first decision on a hardware addition alert is whether a human can vouch for the device within minutes. Start by identifying the device from what the endpoint and network telemetry already hold: the MAC address, the vendor prefix, the USB or Thunderbolt device class, the switch port or access point, and the host it attached to. Then find the owner. Ask the asset inventory and the directory who was assigned that host, check whether the device serial appears in a procurement or asset record, and confirm with the user's manager if the answer is still unclear. Do not rely on the device label alone, because a label is easy to change and a MAC address can be spoofed. Next, check whether a change ticket covers the event. A matching request for a docking station, a replacement keyboard or a lab device, approved before the alert time and naming the same host or port, is the strongest evidence for closing the alert as authorized. Record the ticket number in the case. If no ticket exists, treat the absence as a finding, not a verdict. Contract technicians, facilities staff and vendors often connect hardware without a ticket, so confirm with the site owner before escalating. If the device sits on a port in a segment that carries regulated data, isolate the port or move it to a quarantine VLAN with your switch management tooling, provided your change process allows that action without a further approval. Isolation should be reversible and logged. Preserve evidence before anyone unplugs or reimages anything. Use Velociraptor or an equivalent endpoint tool to collect the process list, active network connections, recently created files, USB device history and the relevant event logs from the host, and store the collection with a hash and a timestamp. Export the switch or wireless controller log for the port and the time window. Escalate to incident response when the device cannot be attributed to an owner, when the port or host shows unexpected outbound connections or new services, or when the device class is an input device or network adapter that the user does not normally use. Close the alert as authorized only when the owner, the ticket and the physical location agree and the endpoint evidence shows no unexpected activity. Confirm your own retention and escalation rules with your security operations and legal teams before you rely on this workflow.
Rehearsing T1200 detection in a private cyber range
Build a small Windows range with a domain-joined workstation, a file server and a Wazuh or equivalent agent on each host, forwarding Windows event logs and Sysmon-style process telemetry to the SIEM. Keep the range isolated from corporate networks and use only devices you own or have written approval to test. Inject two kinds of events: a benign, pre-registered USB peripheral that the endpoint is expected to see, and a simulated unauthorized device described only by its class (for example, a storage device not on the approved list). Confirm with your endpoint vendor which device-installation events are logged by default and which need an audit policy change.
- Expected baseline: Record how the approved device appears in process creation and device-installation logs so the analyst knows what normal looks like.
- Detection logic: Alert when a new device class appears on a host outside a maintenance window, and correlate with a process creation event for the driver or installer where one exists.
- Analyst view: Confirm that the alert shows the host, user session, device class and time, without requiring the analyst to query raw logs.
- Response drill: Practice isolating the endpoint from the range network and preserving the event log before any cleanup.
Check that the time sources on all range hosts are aligned, because device events are only useful when they line up with the session that triggered them.
Stand up Linux hosts with auditd or an equivalent kernel audit source, plus the agent your SIEM uses to collect it. Kernel device events and udev-related logs differ by distribution and init system, so validate each image before writing rules against it. Use injects that represent an approved device and an unapproved one, both described generically, and record exactly which log sources and fields each one produces. Avoid testing against production-like hosts until the rules are stable.
- Source validation: Confirm which kernel and system logs record new block or USB device attachment on each distribution in the range.
- Process correlation: Check whether a new device triggers a mount, a service start or a user session change, and whether that activity appears in process creation telemetry.
- Rule tuning: Test the rule against the approved device first, then add an allowlist keyed to device identifiers recorded in your asset inventory, not to hostnames alone.
- Response drill: Practice unmounting or disabling the device through your standard change process and collecting the relevant logs for the incident record.
Verify that log retention on the range is long enough to replay the full sequence of each inject during the debrief.
Use a small set of macOS endpoints enrolled in the range's device management tool, with unified logging forwarded to the SIEM through the agent you have validated for your environment. Unified log output is verbose and its predicates change between macOS releases, so record the exact macOS version used in each test. Inject a benign approved peripheral and a simulated unapproved device, and capture what the unified log shows for each. Treat the device management tool as a control to test as well, since it may block or report installation before the SIEM sees anything.
- Version pinning: Record the macOS version and agent version for every test run so that rule results can be reproduced later.
- Management correlation: Compare device events in the management console with those in the SIEM and note any gaps in timing or fields.
- Detection logic: Alert on a new device class outside an approved list, and raise the severity when it is combined with an installation or configuration profile change in the same session.
- Response drill: Practice removing the endpoint from managed policy groups and collecting the unified log for the case file.
Confirm with your management vendor which events are exported to your SIEM and which remain only in the console.
Network evidence matters when a device brings its own connectivity, for example a device that obtains an address and begins talking to a remote service. Build a range segment with a switch or virtual switch mirrored to a Zeek or Suricata sensor, and a host that receives DHCP and DNS from the range's own services. Inject an approved device that uses expected addressing and an unapproved one that requests an address from the segment. Keep all traffic inside the range and do not generate connections to real external destinations.
- Address assignment: Alert when a new hardware address requests a lease on a segment where only registered assets should appear, and link it to the switch port where it was seen.
- Port mapping: Maintain a current mapping of switch ports to asset records so an analyst can identify the physical location of an unexpected device.
- Flow baseline: Compare the new device's connection pattern with approved devices of the same class to reduce false positives.
- Response drill: Practice blocking the port or moving the device to a quarantine VLAN, and confirm that the change is logged.
Ask your network team to confirm which switch and firewall logs are available in your environment, because port-level detail often depends on vendor configuration.
Questions SOC leads and detection engineers ask about T1200
How do we reduce noise from legitimate device onboarding?
Start by making onboarding a known, recorded event instead of an exception you filter out later. Route new device enrollments through an approved workflow that writes a ticket or asset record, then have the detection check for network or device events that do not match an approved record. Keep the allowlist narrow and time-bound, keyed to asset identifiers and the onboarding window, not to whole subnets or user groups. Review the suppression list on a fixed schedule so stale exceptions do not quietly hide real activity. Test the allowlist with a few known-good onboarding events in your cyber range before it reaches production.
How do we tell hardware additions apart from other Initial Access techniques?
Hardware additions leave a device-level trail that most other Initial Access techniques do not: a new device appears on a host or network segment, then a new network session or process begins shortly after, often without a corresponding change record. Phishing and drive-by activity usually show up first in user content, browser or mail telemetry. Build your detection around the sequence of device appearance, new connection creation and process activity on the same asset within a short window, and document that logic against the ATT&CK version you target so analysts can separate it from neighboring techniques. Confirm the exact mapping in the ATT&CK technique page for the version your team uses.
Which data components should we prioritize first?
Prioritize Network Connection Creation (DC0082) and Process Creation (DC0032), because ATT&CK detection strategies for Initial Access techniques reference them most often. Application Log Content (DC0038) is the next useful source, since it records device and authentication events that give context to a new connection. Network Traffic Content (DC0085) adds depth where you can inspect it legally and technically, but it is costly to collect at scale, so treat it as a second wave. Confirm which data components your chosen detection strategies reference by reading the relevant STIX bundle for your ATT&CK version, rather than assuming the list is complete for T1200.
How do we test detections without disrupting production?
Test in a private cyber range that mirrors your telemetry pipeline, not in production. Replay benign and simulated hardware-addition events, including approved onboarding, so you can measure false positives before any rule is promoted. Use a staged rollout: alert-only mode first, then a limited set of hosts, then the full fleet. Keep a rollback path for every rule change and record the test results alongside the rule so auditors can see how the detection was validated. DeployOpen can plan and run this kind of exercise as a fixed-scope engagement, with the scope agreed in writing before work starts.
What does the ATT&CK mitigation Limit Hardware Installation mean in practice?
Limit Hardware Installation is the mitigation that restricts who can attach devices and which devices are permitted. In practice, this means endpoint policies that block unapproved device classes, approval steps for new hardware, and physical controls in sensitive areas. Pair it with Limit Access to Resource Over Network, which restricts which network services a newly attached device can reach. Document how each control is enforced, which teams own it, and how exceptions are approved. Confirm the current mitigation wording and mapping on the ATT&CK technique page for your target version before you cite it in an assessment.
How often should we re-map detection rules when ATT&CK changes?
Re-map on every ATT&CK release you adopt, and check the update notes for changes to your techniques. MITRE's recent releases include v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026. Releases can rename, deprecate or revoke techniques, and v18 replaced technique-page detections with detection strategies and analytics, so a rule written for an older version may need rework. Tag every rule with the ATT&CK version it targets, and schedule a review each time you move to a new version. Read the ATT&CK updates page to see what changed.
What should we ask a partner to confirm before starting this work?
Ask for the written scope first: which platforms, which telemetry sources, which ATT&CK version, and which detections are in or out. Confirm who operates the SIEM and sensors after handover, and whether the work includes the cyber range exercise or only the detection build. Ask how false-positive testing is done, what evidence you receive, and how changes are validated before promotion. Clarify what recurs after the engagement, such as rule reviews or ATT&CK version updates, and whether those are covered by a retainer. Request the quote against this written scope so the deliverables and boundaries are clear.
How DeployOpen builds T1200 detections and range exercises
DeployOpen approaches T1200 Hardware additions as a fixed-scope engagement inside your own infrastructure, covering the detections, the telemetry they depend on and the range exercises that prove them. Each step is agreed in writing before work starts, so your team knows what is delivered and what stays with you.
How we scope
- Confirm which endpoint platforms, network segments and physical access points fall within the written scope for T1200 Hardware additions.
- Inventory the telemetry you already collect for Network Connection Creation, Process Creation and Application Log Content, and identify gaps.
- Agree the ATT&CK version the detection mappings will target, so later releases do not silently change coverage.
How we build
- Implement detection logic in open-source tooling such as Wazuh, Sigma rules or Zeek, mapped to the relevant detection strategies.
- Tune rules against your own baseline of approved device connections so that legitimate peripherals do not drive alert noise.
- Configure the Limit Access to Resource Over Network and Limit Hardware Installation mitigations as documented, controlled settings.
How we hand over
- Deliver written detection documentation covering data sources, logic, known false positives and the ATT&CK version targeted.
- Run a private cyber range exercise that simulates an unauthorized device connection and records what your team observed.
- Provide response runbooks and a validation checklist your team can repeat after future changes.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work completes.
- Retest detections when your endpoint fleet, logging pipeline or ATT&CK version changes.
- Ask any provider, including DeployOpen, to confirm in writing which parts of the work recur and which are one-time.
