Detecting T1056 Input capture

How T1056 input capture shows up in intrusions and how to detect it

For a SOC lead, keyboard, mouse and credential input is one of the most valuable collection sources an adversary can reach, because whatever a user types or clicks into a login, administrative console or approval screen often carries the access they want. T1056 Input Capture is the MITRE ATT&CK technique that covers capturing that input. ATT&CK places it under Collection (TA0009), which it defines as "The adversary is trying to gather data of interest to their goal." That definition shapes detection: the question is not only whether input was captured, but which data of interest was reached and what happened to it afterward. Start by agreeing with your team which systems hold privileged credentials and high-value workflows, because those are the hosts and applications where a T1056 detection should be built first.

T1056 has four sub-techniques: T1056.001 Keylogging, T1056.002 GUI Input Capture, T1056.003 Web Portal Capture and T1056.004 Credential API Hooking. The platforms in scope are Linux, macOS, Network Devices and Windows, and coverage varies by platform. Each sub-technique leaves different traces, so a detection that works on a Windows endpoint will say little about a web portal on a network device. Plan one detection entry per sub-technique and platform pair, and record which telemetry supports it, such as process and file activity on endpoints or network content and connection records where the capture touches traffic. Confirm the platform list for each sub-technique on the v20.0 technique pages before you commit coverage, since platform fields are among the parts of an entry most likely to change between releases.

This page targets ATT&CK v20.0, and every detection mapping on it should name that version. MITRE can rename, deprecate or revoke techniques between releases, so a rule written against an older sub-technique list can drift without anyone noticing. Ask whoever maintains your detection catalog to store the ATT&CK version alongside each rule, and review the ATT&CK updates page before each review cycle. The decision to make now is scope: which of the four sub-techniques and four platforms your estate actually runs, and which telemetry you already collect. Where a gap exists, record it as a known risk and do not assume coverage.

Which telemetry reveals input capture and which open-source tool collects it

This table maps the data components ATT&CK references for input capture to the platforms they cover, the signal a defender should look for, and the open-source collector that gathers it. Confirm the exact data component mappings against the ATT&CK version your detections target, since releases can change them. The main takeaway is that keylogging, GUI capture, web portal capture and credential API hooking each need more than one telemetry layer.

Data component	Platforms covered	Signal to look for	Open-source collector
Process Creation (DC0032)	Linux, macOS, Windows	Unexpected helper processes started from user sessions, or unsigned binaries that load input hooks	Sysmon-style Windows logging, auditd, Wazuh agent
File Access (DC0055)	Linux, macOS, Windows	Non-standard processes reading browser profiles, credential stores or input device files	auditd, Wazuh agent logs, Velociraptor hunts
Network Traffic Content (DC0085)	Network Devices, Linux, Windows	Form fields or credentials posted to unfamiliar external hosts, or login pages served from unexpected sources	Zeek HTTP logs, Suricata alerts (confirm visibility under TLS)
Command Execution (DC0064)	Linux, macOS, Windows, Network Devices	Shell activity on network devices that changes logging, mirrors traffic or edits authentication settings	Wazuh collection of device syslog, Velociraptor on endpoints
File Creation (DC0039)	Linux, macOS, Windows	New files in hidden, temporary or application folders holding captured keystrokes or harvested form data	Wazuh file integrity monitoring, Velociraptor artifacts, Sysmon-style file create events

Detection logic for input capture that SOC teams can tune

Input capture detections work best when they are built around a baseline of what legitimate input-handling software does on each platform. The cards below cover four detection ideas, the thresholds and baselines to set for each, and the benign software that most often triggers them.

Unexpected processes reading input devices

Flag processes that open keyboard or pointer input interfaces, such as Linux input event device nodes or Windows raw input and hook APIs, when the process is not on an approved list for that host role. Build the baseline per host group over a period you can justify to the change board, then alert on first-seen binaries rather than on every access. Expect false positives from accessibility tools, remote desktop clients, password managers and input method editor (IME) software, and maintain a named allow list for each. Write the rule in Sigma against Process Creation and Process Access telemetry, and state the ATT&CK version it targets.

New or modified input hooks

Alert when a process installs a global keyboard hook, registers a low-level input callback, or loads a library into a process that normally handles input. Compare each hook against the signed publisher and install path recorded in the baseline, and treat unsigned or user-writable locations as higher priority. Remote desktop agents, screen readers, macro utilities and corporate endpoint agents will all legitimately register hooks, so tune by publisher and path rather than by hook type alone. Map the detection to the relevant ATT&CK data components for Module Load and Process Access and confirm each in your own environment.

Unusual writes of captured input

Watch for processes that create or append to log-style files containing keystroke-like sequences, especially in temporary directories, user profile folders or hidden paths. Set a threshold on write frequency and file growth per process, and correlate with File Creation and File Access events in the same session. Text editors, password manager databases, IME dictionaries and shell history files produce similar writes, so keep a documented exception list per application. Test the threshold in a cyber range using a benign generator that writes at a comparable rate before you deploy it to production.

Exfiltration of input-derived content

On network devices and at network sensors, look for outbound flows that carry input-derived content, such as small, frequent payloads sent to an unfamiliar destination on a schedule. Use Network Traffic Content and Network Connection Creation telemetry, and compare destination reputation and volume against the baseline for each device class. Set alerting thresholds on bytes per interval and on new destinations, and review legitimate telemetry uploads from management and monitoring platforms before tuning them out. Confirm which content fields your sensors can actually parse, because encrypted traffic limits what inspection can show.

Rule governance and version control

Store every T1056 Sigma rule in version control with the ATT&CK version it targets recorded in the rule metadata, so analysts can see when a technique or data component changed. Review each rule after an ATT&CK release, since releases can rename, deprecate or revoke techniques and detection strategies. Record the tuning decisions, exception owners and review dates alongside each rule so auditors can trace why an alert was suppressed. Ask your SIEM or detection platform vendor to confirm how it imports Sigma rules and maps them to ATT&CK identifiers.

How to validate that an input capture detection fires

This sequence proves that detections for T1056 Input Capture and its sub-techniques fire on the telemetry they depend on, under agreed rules, in a private cyber range. It ends with a documented coverage record that names what was detected, what was missed and who owns each gap.

Scope the techniques and platforms under test
The detection owner and the security engineering lead list which T1056 sub-techniques and platforms are in scope, such as Linux, macOS, network devices and Windows, and map each one to the ATT&CK version the detection targets. Confirm the mapping against the current technique page on the MITRE ATT&CK site, since releases can rename or deprecate techniques. The step is done when every in-scope sub-technique has a named detection, a named data source and a named owner.
Agree rules of engagement with stakeholders
The CISO's delegate, the platform team, the range operator and the change owner sign a written rules of engagement document. It states which range hosts and accounts may be touched, which network segments are off limits, how the exercise is stopped, who receives alerts during the run and how evidence is handled afterward. The step is done when all signatories have approved the document and the range operator has confirmed the isolation controls are in place.
Select an approved benign emulation plan
The red team or range lead selects a benign emulation plan that is mapped to T1056 and each in-scope sub-technique, and that uses only behavior approved in the rules of engagement. The plan should describe the expected observable effects in plain language, such as the telemetry each step should produce, rather than operational detail. The step is done when a reviewer has checked that every planned action traces back to a scoped sub-technique and the expected telemetry is written beside it.
Run the emulation with a timestamped log
The emulation operator runs the approved plan on the range while a second person keeps a timestamped log of each step, its start and stop times and any deviation from the plan. Analysts watch the Wazuh, Security Onion or other configured console without prior knowledge of the step timing, so the test reflects real triage conditions. The step is done when the operator's log and the plan line up one to one and no unplanned activity has reached systems outside scope.
Check alert fidelity against expected telemetry
The detection engineer compares each fired alert with the expected telemetry for its step, checking that the relevant data components, such as Process Creation, File Access and Network Traffic Content, were collected from the right hosts and that the alert fields identify the affected account, host and time. Alerts that fire for the wrong reason, or that fire without the expected fields, are recorded as fidelity defects rather than passes. The step is done when every step has a verdict of detected with fidelity, detected with defects or not detected.
Record coverage gaps and assign remediation
The detection engineer writes a coverage record that lists each sub-technique, the telemetry source, the verdict and the cause of any gap, such as a missing log source, an unparsed field or a rule that was never enabled. Each gap receives a named owner and a ticket in the agreed backlog. The step is done when the record has been reviewed by the security engineering lead and every gap has an owner and a next action.
Re-test fixes and retain the evidence
After owners close their gaps, the range operator repeats the affected steps against the same plan and compares the new results with the earlier record. The compliance lead files the coverage record, the rules of engagement, the emulation log and the re-test results together so an independent assessor can trace them. The step is done when re-tests confirm each fix and the evidence package is stored with its ATT&CK version noted.

Why the four T1056 sub-techniques need separate detection coverage

The four T1056 sub-techniques differ by where the captured input comes from, so a single detection rarely covers them all. Keylogging records keystrokes at the operating system input layer on a host. GUI input capture takes input through graphical interface and operating system interfaces. Web portal capture targets what users type into login and form pages, which moves the signal toward browser, web server and network content. Credential API hooking intercepts calls that handle credentials inside a process, so its evidence sits in module loads and process behavior. Each path leaves different traces on different platforms, and a rule written for Windows endpoints will not see a web portal problem on a server. Treat the four as separate detection problems that share one technique ID.

Map each sub-technique to its own data sources and an accountable owner before writing any rule. A practical starting point is a coverage table with columns for sub-technique, platform, data component, telemetry source and the team that answers the alert. As an illustrative example, Process Creation (DC0032) and Command Execution (DC0064) on endpoints may belong to the endpoint security team, while Network Traffic Content (DC0085) for portal exposure may belong to the application security or network team. Confirm the sub-technique names, IDs and data component references against the enterprise-attack 20.0 STIX bundle, which is the version these pages target, and do not rely on memory or older mappings. Ask each owner to confirm which telemetry their platforms actually collect.

Record the ATT&CK version beside every mapping, because releases can rename, deprecate or revoke techniques. ATT&CK v18 already moved detection content into detection strategies and analytics, so older rule references may no longer line up with the current pages. Before the cyber range rehearsal, check each row for two things: whether the telemetry exists on that platform, and whether the alert has a named owner who can act on it outside business hours. Rows missing either are gaps to close with the client before any tuning begins. This matters most for credential API hooking and web portal capture, where telemetry is often spread across teams and the first alert may land in a queue nobody reads.

Preventive controls that reduce input capture risk

Input capture succeeds when a captured keystroke, credential or session token is still useful to the adversary. The six ATT&CK mitigations below mostly cut that value: they limit which credentials are usable, who can act on them, and what sensitive data is exposed. Confirm each mapping to T1056 on the ATT&CK mitigation page for the version you target.

Multi-factor authentication (M1032)

A password captured by a keylogger or a fake login prompt is less useful when a second factor is also required at sign-in. For T1056 Input capture, the key check is coverage: list every administrative, remote access, email and SaaS login path and confirm each one enforces a second factor that cannot be replayed from the captured password alone. Pay attention to legacy protocols and service accounts that often bypass the prompt. Confirm the M1032 mapping for T1056 in the ATT&CK mitigation page for your version.

User training (M1017)

Users are often the point where input is captured, through phishing pages that mimic a login form or a malicious browser extension that reads typed text. Training should teach staff to recognize credential prompts that appear outside the expected identity provider and to report unexpected password requests. Measure whether reports reach the security team and whether the training covers extensions and remote support tools. Confirm the M1017 mapping in the ATT&CK mitigation page for your version.

User account management (M1018)

Captured input is worth more when the account it belongs to has broad rights. Limit privileged accounts, remove dormant accounts and separate administrative identities from daily-use identities. Review which accounts can log in interactively to servers and network devices, since a keystroke capture on those hosts exposes high-value credentials. Confirm the M1018 mapping for T1056 in the ATT&CK mitigation page for your version.

Audit (M1047)

Audit does not stop capture by itself, but it shortens the time a captured credential remains unnoticed. Confirm that authentication events, new services or drivers, and changes to privileged group membership are logged and forwarded to a central platform such as Wazuh, where they can be correlated with unusual logins. Check retention, time synchronization and whether logs can be altered on the host. Confirm the M1047 mapping in the ATT&CK mitigation page for your version.

Encrypt sensitive information (M1041)

Encryption limits what a captured or intercepted secret reveals. Where sensitive data is handled, confirm that secrets are not stored in plain text in configuration files, shell history or application logs, and that traffic carrying credentials uses protected transport. Note that encryption in transit does not protect a password typed into a compromised endpoint, so pair it with the other controls. Confirm the M1041 mapping for T1056 in the ATT&CK mitigation page for your version.

Data loss prevention (M1057)

Even when input is captured, DLP can limit whether sensitive content leaves the environment. Define rules that flag or block transfers of credential-like strings, card numbers or regulated identifiers in email, web uploads and endpoint channels. Test rules against your own data classes, since false positives erode trust quickly. Confirm the M1057 mapping in the ATT&CK mitigation page for your version.

What to do when an input capture alert fires

When an input capture alert fires, the first decision is whether the alert is real. Compare the alert against the raw telemetry that produced it: the process or module involved, the file path or hook it touched, and the network content if one was captured. Confirm which account was logged in when the activity happened and which host it ran on, because a keystroke logger or credential prompt spoof usually runs in the context of the user who typed the secret. Record the user, host, timestamps and the detection logic version so the finding can be traced later. Discard only what the raw data clearly shows to be benign, such as a known password manager or accessibility tool that your asset inventory already lists, and record why it was dismissed.

Once the alert is confirmed, define scope before containment. Identify every host where the same binary, file hash, persistence entry or keyboard hook appears, and every account that signed in to those hosts during the suspected window. Isolate affected endpoints using the controls your EDR or network team already operates, and avoid rebooting them until volatile evidence is captured. Assume that any password, one-time code or session token typed on a compromised system may have been exposed, and treat rotation as a decision to make early: reset affected credentials, revoke active sessions and review whether multi-factor prompts were approved from the same device. Confirm with your identity team how long rotation takes for privileged and service accounts before you promise a timeline to stakeholders.

Preserve evidence before cleanup changes the host. Capture memory and disk images according to your forensic procedure, export the relevant logs, and keep chain-of-custody records for anything that may support a legal or regulatory notification. Then review adjacent Collection and Credential Access activity on the same accounts and hosts, including archiving, staging and browser session access, because input capture is often one step in a longer sequence. Align every step in this playbook with your own incident response plan, including who approves containment, who contacts legal and when regulators must be notified. Test that plan in your cyber range so the on-call team knows these steps before a real alert arrives.

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

A Windows range should contain a small Active Directory domain, a few workstations with a standard endpoint agent, and a Wazuh or Security Onion collector receiving events. Input capture on Windows is usually tested through process creation, file access and module load telemetry, so the range needs event logging tuned to capture those sources. The benign injects should be scripted and labeled, for example an illustrative helper process that a red team agrees to launch under a known test account to read keyboard-related state, with the exercise owner recording the exact start time.

Range topology: one domain controller, two workstations and one collector, with logging policy documented in the exercise plan.
Benign injects: a labeled test binary that touches an input-related API, agreed in writing and removed after the run.
Expected telemetry: process creation events with parent and command context, plus file access events on any staged output file.
Good response: the alert reaches the analyst queue, the analyst identifies the host and account, and containment is documented as a decision, not a reflex.
Observed metric: record time to triage for each inject as an observation in the exercise log and compare it across runs.

Confirm with your endpoint vendor which audit subcategories and telemetry channels are available in your Windows version before you design the injects.

Questions SOC leads and detection engineers ask about T1056

How do you tell a legitimate input tool from input capture?

Start with a baseline of which processes are expected to hook keyboard or mouse input on each host class, then alert on deviations rather than on the API call alone. Input capture logic is shared by accessibility software, remote support tools, text expansion utilities, password managers and game peripherals, so a single signal rarely decides the question. Useful context includes the parent process, the binary's signing state and publisher, the install path, whether the process runs from a user-writable location, and whether it also writes to a file or opens a network connection shortly afterward. Confirm the expected list with the business owners of each endpoint group before you tune alerts, and record each approved tool with its owner and review date.

How should detection handle ATT&CK version changes for T1056?

Pin every detection mapping to the ATT&CK version it targets, and record that version in the rule metadata and in your coverage register. ATT&CK v18 replaced technique-level detections with detection strategies and analytics and made major updates to data components, so a rule written against older text may map to different data components today. The Enterprise ATT&CK 20.0 STIX bundle is the reference to diff against when a new release arrives. Review the T1056 entry and its sub-techniques at each release, check whether any were renamed, deprecated or revoked, and update your mappings in the same change window as your rule changes.

Is network-only detection enough for input capture on network devices?

Usually no. Network-level signals such as Network Traffic Content and Network Connection Creation can reveal exfiltration of captured credentials or keystroke data, but they do not show the capture itself, and many network devices offer little endpoint-style telemetry. Plan for layered coverage: collect device logs that record administrative logins and configuration changes, watch for unexpected management sessions and new accounts, and correlate those with outbound transfers from management networks. Ask each device vendor which audit events and syslog categories they can export, because the exact fields vary by product and firmware. Document the gaps you cannot close as accepted risks with a named owner.

How do you test T1056 detections without live credentials?

Test with synthetic data in a private cyber range rather than on production users or real secrets. Use dummy accounts, lab credentials that carry no access and test data that matches your expected formats, and run the behavior on isolated test hosts that mirror your endpoint build. Each exercise should have a written scope, a rollback plan and a named approver. The goal is to confirm that telemetry is collected, parsed and alerted on, not to capture anything real. Record the exact test conditions so the same exercise can be repeated after each rule change or ATT&CK update.

How do you measure detection coverage for input capture?

Measure coverage per platform and per sub-technique, not as a single yes or no for T1056. For each of Linux, macOS, network devices and Windows, record which data components feed the detection, whether the log source is collected from every in-scope host, whether the rule fires on a repeatable test, and how often the alert reaches a triage queue. Track the percentage of in-scope hosts reporting the required telemetry, and treat gaps in collection as coverage failures even when the rule logic is sound. Review the register after each cyber range exercise and after each ATT&CK release.

Which telemetry should you collect first for T1056?

Prioritize the data components that the ATT&CK entries most often reference for Collection techniques: Process Creation, File Access, Command Execution, Network Traffic Content and Network Connection Creation. Process Creation and File Access give the most immediate host context on Windows, Linux and macOS, while network content and connection data help correlate later exfiltration. Confirm in your own environment which of these your agents, such as Wazuh agents or Velociraptor clients, can actually produce, and which need additional audit policy or sensor configuration. Log volume and retention will drive storage costs, so set collection scope before you enable verbose auditing everywhere.

Can our own team run this detection program, and what does DeployOpen add?

Yes, a capable internal team can build and run this program, provided it has access to the endpoint, network and log sources and time to tune rules. The work breaks into planning the telemetry, writing and testing rules, building the cyber range, running exercises and maintaining the coverage register. DeployOpen plans, implements, integrates and documents self-hosted open-source platforms in your own infrastructure, runs security testing and operates private cyber ranges, and can support this work under a fixed scope agreed in writing. DeployOpen does not issue audit reports or certifications, so independent assessors still review your controls. Ask any partner to show the telemetry sources and test evidence they will deliver.

Primary sources for T1056 detection mapping

Before you write or approve any detection for T1056 Input capture, confirm the technique and its four sub-technique definitions against the primary MITRE sources, because the detection logic is only as current as the ATT&CK version it targets. Start with the MITRE ATT&CK tactic page for Collection, which sets the tactic context in which T1056 sits, and then check the technique page itself for the sub-technique list, the platforms it covers and the detection strategies currently attached to it. Record the ATT&CK version you checked in every detection ticket, since releases can rename, deprecate or revoke techniques and a mapping that was correct for one version may need revision for the next.

Next, read the ATT&CK updates page and the release notes for the two most recent changes that affect this technique. The ATT&CK v18 release notes describe the move from technique-level detections to detection strategies and analytics, along with changes to data components and the deprecation of data sources, which directly affects how a Process Creation or File Access rule for input capture is named and traced. The ATT&CK v19 release notes cover the next revision, so compare both against your current rule library and log a change record for any mapping that moved.

For a machine-checkable baseline, download the enterprise-attack 20.0 bundle from the mitre-attack/attack-stix-data repository and query it for T1056 and its sub-techniques. Confirm the object IDs, the data component references in each detection strategy and any revoked or deprecated objects, then store a dated copy in your detection-as-code repository so audit evidence shows which definitions your rules were built against. Ask your DeployOpen team or your internal detection engineers to confirm that the platform list for T1056 matches the operating systems you actually run, since coverage gaps usually start with an assumption about platforms that was never checked against the bundle.

How DeployOpen builds T1056 detections, purple team exercises and range scenarios

DeployOpen works on T1056 Input capture as a fixed-scope engagement inside the client's own infrastructure. The work turns the technique's sub-techniques and platform coverage into detections, tests them in a private cyber range and documents what the client's team can run afterward.

How we scope

Confirm which platforms are in the written scope, such as Linux, macOS, Windows and network devices, and which sub-techniques each platform covers.
Inventory the telemetry the client already collects, including Process Creation, File Access and Network Traffic Content, and note any gaps in logging.
Agree the target ATT&CK version, such as v20.0, so detection mappings stay tied to a specific release.

How we build

Write detection logic for T1056 sub-techniques as Sigma rules and map each rule to the relevant detection strategy and data components.
Deploy and tune the rules in the client's Wazuh, Security Onion, Suricata or Zeek stack, adjusting for the client's normal administrative input tools.
Document known false positives, such as legitimate accessibility, remote support or keyboard-hook software, with the tuning decision behind each one.

How we hand over

Deliver a written test plan that lists each detection, the simulated behavior in the cyber range, the expected alert and the pass criteria.
Provide a range scenario runbook so the client's security team can rehearse T1056 detection and response without outside help.
Record the validation results, open gaps and recommended mitigations, such as User Training and Audit, in a handover document.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer when the client wants detections kept current across ATT&CK releases.
Confirm with DeployOpen during scoping which support terms, review cycles and exercise frequency apply to your environment.

T1056 Input capture