Detecting T1674 Input injection

How T1674 input injection fits into Execution and where it shows up in intrusions

A SOC lead or detection engineer mapping Execution coverage needs to know exactly what T1674 Input Injection covers before writing any rule. In short, T1674 describes adversaries running instructions on a system by feeding synthetic input into it, so the target responds as though a person had typed or clicked. The MITRE ATT&CK tactic page for Execution defines the tactic, TA0002, as follows: "The adversary is trying to run malicious code or instructions on a system." Technique IDs follow the form T####, with sub-techniques adding a three-digit suffix such as T1059.001. A technique can belong to more than one tactic, so confirm the Execution label from the technique's own tactic list before assuming it. This page targets Enterprise ATT&CK 20.0.

Input injection matters to Execution coverage because it is an execution path that does not always look like a program launch. At a high level, it appears in intrusions after an adversary already has some foothold on a host or session, where the goal is to make an existing, trusted interactive context carry out instructions. Defenders should review endpoints with long-lived user sessions, virtual desktop and remote administration sessions, and systems where software can generate input events. Confirm the platforms and tactic list for T1674 in the ATT&CK 20.0 STIX bundle for your own mapping. ATT&CK v18 moved detections into detection strategies and analytics and deprecated data sources, so older rule notes may cite retired structures. The ATT&CK v18 release notes explain that change.

Three decisions follow for the coverage map. First, record the ATT&CK version (20.0) next to every T1674 mapping, because releases can rename, deprecate or revoke techniques. Second, check which data components your telemetry actually supports. Process Creation (DC0032) and Command Execution (DC0064) are the components most often referenced across Execution techniques, but whether they reveal the effect of injected input on your platforms is something to test, not assume. Third, decide who owns the gap if your sensors cannot see the input source, such as an endpoint team or a virtualization administrator. Use the cyber range exercise later on this page to prove each mapping before it is trusted.

Which telemetry reveals T1674 input injection on Windows, macOS and Linux

This table maps the telemetry that can reveal T1674 input injection on each platform, along with the open-source collector that gathers it. Read each row as a question: can this platform record the signal, and which collector captures it. The main takeaway is that process and command telemetry carries most of the signal, while script activity and network context depend on your own environment and on confirmation in the STIX bundle.

Platform or signal	Telemetry to collect	Open-source collector	What to confirm
Windows	Process Creation (DC0032) with parent process, image path and command line	Sysmon process logs forwarded by the Wazuh agent	Confirm the T1674 data component mapping in the enterprise-attack 20.0 STIX bundle
Windows	Script Execution, including script host launches and their arguments	Wazuh agent collecting script host logs where enabled	Script Execution has no DC ID in the researched facts; confirm its ATT&CK mapping
macOS	Process Creation (DC0032) and Command Execution (DC0064) from process and shell events	Wazuh agent on macOS, with osquery or endpoint audit logs	Confirm which macOS log sources your agent version supports in your fleet
Linux	Process Creation (DC0032) and Command Execution (DC0064) from audited process records	auditd rules forwarded to the Wazuh agent	Confirm the audit rule set covers the process events the detection needs
Linux	Script Execution from interpreter launches and script file paths	auditd or Wazuh log collection, within your logging policy	Interpreter launch context varies by distribution; test on each target build
All platforms	Process chains that begin shortly after an input session event (illustrative)	Velociraptor hunts across endpoints for matching process chains	Confirm which input or session events your endpoints record; not in the researched facts
Network context	Remote session or connection events preceding local process starts, where the scenario includes them	Zeek or Suricata sensors	Input injection is largely local, so network value depends on the scenario you test
Mitigation check	Execution Prevention (M1038) enforcement events and blocked execution alerts	Wazuh alerts from endpoint prevention logs	Confirm the Limit Hardware Installation mapping for T1674 in the STIX bundle

Detection logic for T1674 that SOC teams can tune

The ideas below describe what to look for in process, script and command telemetry when T1674 Input Injection occurs, and what context separates it from legitimate activity. Each card names one detection pattern and the checks that connect it to a host, user or parent process. Treat every threshold as a starting point to set against your own baseline.

Input-generating process creation

Alert on process creation events for tools that can send synthetic keyboard or mouse input when the parent process, image path or signer is outside your approved baseline. For T1674 Input Injection, the useful question is whether the process has a business reason to inject input on that host. Record the parent chain, the logon session type and whether the process started from a user profile directory or a temporary path. Set the alert threshold from observed frequency per host group, not from a fixed count.

Script execution after input activity

Correlate a scripting interpreter starting shortly after an input-generating process on the same host and session. The sequence matters more than either event alone, so use a short correlation window that you tune per endpoint population. Check whether the interpreter was launched interactively, by a service account or by a scheduled context. Scripts that open at unusual hours, or that run without a console session, deserve faster triage.

Host role and session context

Group detections by host role, since a developer workstation, a kiosk, a domain controller and a jump host carry very different expectations for input injection. Enrich each event with the user, the account type, the logon type and whether the session is remote or local. An input-generating process on a server with no interactive users is a stronger signal than the same process on a shared design workstation. Keep the role mapping in your asset inventory so analysts can read it during triage.

Known false positive sources

Expect accessibility tools, remote support software, admin automation and keyboard layout utilities to generate legitimate input events. Build allowlists from signed binaries, publisher names and deployment tooling rather than from file names, since file names are easy to change. Review every allowlist entry on a fixed schedule and after each software change window. Ask your endpoint vendor and your remote support vendor which of their executables send synthetic input so the list reflects reality.

Writing Sigma rules for ATT&CK 20.0

Write each Sigma rule against the ATT&CK version under test, and record that version in the rule metadata and the detection inventory. This project targets Enterprise ATT&CK 20.0, so confirm T1674 and its tactic mapping in the matching STIX bundle before you map a rule to it. Releases can rename or revoke techniques, so re-check mappings after each update. Keep a changelog for every rule that records why a field, threshold or allowlist changed.

Validating detections in the cyber range

Replay the same event pattern in a private cyber range before promoting any rule to production, and record which fields fired and which were missing. Run the benign sources you expect in production, such as accessibility tools and remote support sessions, so you measure the false positive rate against real workflows. Compare results across Windows, macOS and Linux hosts, because the telemetry names and fields differ by platform. Document each tuning decision so the rule can be audited later.

How to validate that the T1674 detection fires

This sequence turns a T1674 detection from a rule on paper into evidence that it fires on Windows, macOS and Linux telemetry, and shows where coverage has gaps. It produces a scoped test record, an event trail per platform, and a tuning log that an auditor or internal reviewer can follow.

Agree scope and rules of engagement
The detection owner, the platform owners and the cyber range lead agree in writing which hosts, accounts and data sources the test may touch, which ATT&CK version the mapping targets, and who can stop the exercise. Name the ATT&CK version explicitly, because releases can rename or deprecate techniques. The step is done when a signed scope note exists and every system in it is confirmed as a range or lab asset, not production.
Select an ATT&CK-aligned emulation plan
Choose an emulation plan from a library that maps its steps to ATT&CK technique and sub-technique IDs, and confirm that the plan covers T1674 Input Injection on each platform in scope. Review the plan with the detection engineer so that the steps are described at the level of the behavior being tested, and any step that would need operational detail is handled by the team running the range. The step is done when the plan is approved and mapped to the detection rule IDs it should trigger.
Define expected telemetry per platform
Before the run, write down the events each platform should produce, using the data components the detection depends on, such as Process Creation, Command Execution and Script Execution. List the log source, the expected field values and the collector that should forward them, for Windows, macOS and Linux separately. The step is done when this expectation sheet is reviewed, because it is the baseline that the test result will be compared against.
Run the emulation in the range
The emulation operator executes the approved steps in the isolated range, one platform at a time, and logs the start and end time of each step in the exercise record. Observers from the detection team watch the SIEM or Wazuh dashboard during the run without changing rules. The step is done when every planned step has a recorded start, end and operator note, including any step that was skipped and why.
Record which events arrived
Compare the events that reached the SIEM against the expectation sheet. For each expected event, record whether it arrived, the arrival delay, whether required fields were populated and whether the rule raised an alert with the expected severity. Store raw event identifiers, rule IDs and screenshots or exports in the exercise folder. The step is done when every expected event has a status of arrived, partial or missing, with evidence attached.
Track gaps and tuning changes
Open a tracked item for each missing or partial event and for each alert that fired without the expected context. Assign an owner to each item, classify the cause (collection, parsing, rule logic, or noise), and change one variable at a time before re-running the affected step. The step is done when each gap has a closed status or an accepted-risk entry signed by the owner.
Retain audit evidence for the assessment
Package the scope note, ATT&CK version, emulation plan reference, expectation sheet, event trail, alert records, gap log and tuning history into one dated evidence set for the exercise. Include the rule version tested and the rule version deployed after tuning. Confirm with the internal audit or compliance lead which controls this evidence supports, since DeployOpen prepares evidence but independent auditors decide whether it meets a given requirement. The step is done when the evidence set is stored in the designated repository and the reviewer has acknowledged receipt.

Platform-specific detection notes for Windows, macOS and Linux

On Windows, input injection usually shows up as a user-facing process or a script host that starts other processes and then produces synthetic keyboard or mouse events. Detection depends on process creation records with full command lines, PowerShell script block logging, and endpoint telemetry that records which process is in the foreground. Collect these through Sysmon or your EDR, and forward Windows event channels to Wazuh or another SIEM.

Process lineage: Alert when a script host or scripting engine launches a child process that then takes foreground focus, especially on servers that should not have an interactive user.
Script content: Use script block logging to flag scripts that call input-simulation APIs without a documented business purpose.
Session context: Correlate events with remote session logons, since injected input in a remote session is harder to attribute.
Benign look-alikes: Accessibility tools, password managers, help desk remote support, and RPA bots all generate similar events.
Tuning: Build an allowlist of signed binaries with a named owner and a host group, then review new entries before they expire.

Before going live, confirm that your agent captures command lines and script block content on every server class in scope.

Preventive controls: Execution Prevention and Limit Hardware Installation

These controls limit what injected input can do once it reaches a host, and which devices can deliver that input in the first place. Execution Prevention and hardware limits work together, while behavior monitoring and audit logging confirm that the preventive layer is working as designed.

Execution Prevention (M1038)

Execution Prevention is the ATT&CK mitigation for blocking code that is not approved from running. For T1674 Input injection, the goal is that keystroke-driven actions cannot launch unapproved shells, script interpreters or binaries, even when a device types commands on a user's behalf. Check that application control policies cover command shells and scripting interpreters on Windows, macOS and Linux. In a cyber range, confirm that an unsigned or unlisted binary is blocked and that the block is logged.

Limit Hardware Installation

This mitigation restricts which peripheral devices endpoints accept, so an unknown device that emulates a keyboard can be refused before it sends any input. Define approved device classes and identifiers for each fleet, and name who may approve exceptions and how long they last. The ATT&CK ID for this mitigation must be confirmed in the enterprise-attack 20.0 bundle before it appears in any control mapping or audit evidence. Device control is configured differently on each operating system, so test each fleet separately.

Behavior Prevention on Endpoint (M1040)

Behavior Prevention on Endpoint covers controls that stop suspicious process behavior even when the binary itself is trusted. For input injection, flag a keyboard-like device followed quickly by a shell, a script interpreter or a network download. Tune these rules with Process Creation telemetry from your endpoint agent, and keep the parent process and device identity in each event. Test the rule in a cyber range by replaying a scripted input pattern that you own, and record which hosts run the rule and which do not.

Audit (M1047)

Audit is the mitigation that makes the other controls verifiable. Enable operating system logging for process creation, removable device connection and script execution on Windows, macOS and Linux, then forward those events to a central store such as Wazuh or Security Onion. Every event must record the device identity and the parent process, or an investigator cannot tie a typed command to the device that sent it. Agree on log retention with your compliance lead before rollout.

Version-checked control mappings

Every mapping of these controls should name the ATT&CK version it targets, because releases can rename, deprecate or revoke techniques and mitigations. Re-check each mitigation ID against the STIX bundle for that version whenever MITRE publishes an update. Keep a dated record of each mapping change, who approved it and which detections were retested afterward.

Triage and response when a T1674 detection fires

The first decision is whether the alert matches an approved activity. Before anyone isolates a host, the analyst should confirm with the asset owner and the change calendar whether a sanctioned peripheral, driver, input utility or automation job explains the Process Creation, Command Execution or Script Execution events. Record the rule name, the ATT&CK version it targets and the exact telemetry fields that fired. Then scope the activity: pull the same process lineage, command patterns and script events for the affected host, the logged-in user and the other endpoints that share the same image hash or deployment group. If the same pattern appears across a fleet, treat it as a configuration or distribution question first and an intrusion question second.

If the activity cannot be explained, preserve volatile evidence before containment changes the system state. Capture the running process list, active sessions, loaded modules and network connections, and collect the relevant event logs to write-once storage with hashes recorded. Memory capture is appropriate only where your evidence policy and the asset owner allow it. Containment is a business decision as well as a security one. Options range from disabling a user session or blocking a hash to isolating the endpoint, and the right choice depends on whether the host runs a process that cannot tolerate interruption. Check the Limit Hardware Installation and Execution Prevention settings for the host to see whether a block or a device approval is already recorded.

Document the timeline as you go: alert time, triage decisions, who approved each action and when containment took effect. Feed every confirmed false positive back into tuning, but change the rule through version control, add a narrow exclusion with an owner and review date, and test the change in a private cyber range before production. Compliance readiness depends on this record. Map the evidence to the controls your assessor will ask about, keep it factual, and state the outcome of the investigation rather than a compliance result, since only an independent auditor or certification body can issue an audit outcome. Confirm the ATT&CK version your rules target against the ATT&CK updates page before each release cycle.

How to rehearse T1674 detection and response in a private cyber range

The range should mirror the operating systems and sensor layout of the production estate closely enough that detection results carry over. Most teams build a small set of Windows, macOS and Linux endpoints enrolled in Wazuh agents, with a Security Onion sensor watching the network segment. The range sits in its own network segment, with no route to production identity stores or business data, and every test account is synthetic.

Endpoint coverage: Include at least one Windows, one macOS and one Linux endpoint, because T1674 telemetry differs by platform.
Logging baseline: Confirm that process creation, command execution and script execution events reach the SIEM before any inject runs.
Sensor placement: Position Security Onion or a comparable network sensor so that Zeek and Suricata see the same segment as the endpoints.
Isolation controls: Document the range boundary, snapshot policy and reset procedure in writing.
Version pinning: Record the ATT&CK version the detection mapping targets, such as v20, so later results can be compared.

Confirm with your platform team which Wazuh and Security Onion versions the range will run, and whether the lab telemetry matches production log formats.

Questions SOC leads and detection engineers ask about T1674

How do we handle ATT&CK version changes between v18, v19 and v20 for T1674?

Pin every detection to one named ATT&CK version and record that version in the rule metadata. ATT&CK v18 (released October 28, 2025) replaced detections in technique pages with detection strategies and analytics, and later releases can rename, deprecate or revoke techniques. Before you move a mapping from one version to another, compare the STIX bundle for the technique and its sub-techniques against your current version. Keep a mapping table that links each Sigma or Wazuh rule ID to its technique ID, data component and ATT&CK version, so that a renamed or revoked ID can be found with one query. Review the ATT&CK updates page at each release cycle and record the outcome in your change log.

Which data components should we confirm before writing an Input Injection detection?

Start with the data components that the current ATT&CK bundle lists for T1674, and confirm them there rather than relying on memory or a blog post. Process Creation (DC0032) and Command Execution (DC0064) are the data components most often referenced by Execution techniques, so they are a sensible baseline, but you must check whether T1674 references them in your target version. For each component, confirm three things: which operating systems you collect it on, whether the events are complete enough to reconstruct parent and child process relationships, and whether the collector is running on every in-scope endpoint. A detection built on a data component you collect only partially will look correct in a lab and fail in production.

How do we reduce false positives from admin and remote support tooling?

Tune the rule on context that an attacker cannot easily copy, and document every exception. Useful conditions include the signed publisher of the binary, the parent process, the host group, the account type and the time window of an approved change. Keep allowlists narrow and tie each entry to a named owner, a ticket and an expiry date, so that exceptions do not quietly become blind spots. Review the alert volume per rule each week during the first month after deployment. Where a benign tool keeps matching, record the tool, its version and the business reason in the rule notes so that an auditor or a new analyst can follow the decision.

How do we measure detection coverage for Input Injection across our estate?

Measure coverage as two separate numbers: the share of in-scope endpoints that send the required telemetry, and the share of rehearsed test scenarios that produce an alert. Coverage on paper, where a technique is mapped to a rule, does not show that the rule fires on your hosts. Break both measures down by operating system (Windows, macOS and Linux) and by host group, because collector health often differs between them. Use your SIEM or Wazuh agent status data to find silent endpoints, and treat a host that stops reporting as a coverage gap. Record the ATT&CK version used for the mapping alongside each result, so the measurement stays comparable after the next release.

How do we validate the detection without risking production systems?

Validate in an isolated environment that mirrors your production logging pipeline, not in a clean lab with different collectors. Use a private cyber range with dedicated test endpoints, snapshot them before each exercise, and run each scenario under a written change record that names the operator, the window and the rollback plan. Confirm that the alert reaches the analyst queue, that the enrichment fields are populated and that the case is routed to the correct team. Record the outcome per scenario, including misses. Only promote a rule to production after the same test passes twice on separate days, and keep the test scripts under version control. Operators should not improvise attack steps on production hosts.

Can our internal team run this detection program, or do we need outside help?

It depends on your team's logging, detection engineering and range-operations skills, and on how many platforms are in scope. Internal teams can often own the rule logic, the ATT&CK mapping and the analyst runbooks, while outside help is commonly used for telemetry pipeline design, cyber range setup and the first round of validation. DeployOpen implements and documents self-hosted open-source platforms inside your own infrastructure, runs security testing and private cyber ranges, and offers fixed-scope engagements with agreed deliverables, plus retainers for ongoing testing and support. Ask any provider to state in writing which parts they will hand over, which parts you will run yourself and how knowledge transfer will be verified.

How DeployOpen builds T1674 detections and range exercises

DeployOpen approaches T1674 Input injection as an engineering and testing task inside your own environment. Detections are built on the telemetry your platforms already produce, such as process creation, command execution and script execution, and are validated before handover. Work is scoped in writing before it starts.

How we scope

Written scope naming the platforms, log sources and endpoints in T1674 coverage
Confirmed list of Windows, macOS and Linux telemetry available for process creation, command execution and script execution
Agreed mitigation review covering Execution Prevention and Limit Hardware Installation, with owners named for each control

How we build

Detection logic for T1674 written as Sigma rules, mapped to the ATT&CK version the team targets
Ingestion and parsing checks in the client's SIEM, such as Wazuh or Security Onion, so rules receive the fields they expect
Test cases for benign administrative activity, so analysts can tell routine automation from suspicious input injection

How we hand over

Rule documentation covering logic, data dependencies, known false positives and the ATT&CK version tested
Range exercise runbook for rehearsing detection and response in DeployOpen's private cyber range
Evidence pack describing what was tested, what fired and what gaps remain open for the client to decide

How we support

Optional retainer for rule tuning as platforms, log sources and ATT&CK versions change
Periodic re-testing of T1674 detections after platform upgrades, with results reported to the client
Ongoing support is available as a retainer, and scope changes are agreed in writing before work starts

T1674 Input injection