How T1115 clipboard data collection shows up in your environment
A process reading clipboard contents it has no business reading is the signal the SOC lead needs to find. ATT&CK technique T1115, Clipboard Data, describes adversaries collecting data from the system clipboard, the short-term buffer where copied passwords, account numbers, tokens and document text sit between a copy and a paste. In Enterprise ATT&CK, the technique sits under the Collection tactic (TA0009), whose stated purpose is gathering data of interest to the adversary's goal. It is easy to miss because clipboard reads look like ordinary desktop activity. Copy and paste generate no file, no network session and no alert in most default logging, so the activity blends into normal user behavior unless you deliberately instrument the processes that touch the clipboard. The page targets Enterprise ATT&CK 20.0, and the mapping should be checked against that version before you build rules on it. ATT&CK releases can rename, deprecate or revoke techniques and change how detections are described, so record the version alongside every detection you write. Confirm the current technique name, its platforms and its linked detection strategies and data components in the STIX bundle for the version you have adopted, since the data components a rule depends on are the first thing to change between releases. Your detection engineering team should also confirm which of the data components referenced for Collection techniques, such as Process Creation or Process Access, your Wazuh, Sysmon or EDR sources actually provide on each operating system in scope. The practical decision is which hosts and user populations justify clipboard-level visibility. Privileged administrator workstations, finance and treasury desktops, and build or secrets-handling systems are usually the first candidates, because the data copied there is most valuable to an adversary and most costly to lose. Agree that scope with the SOC lead, the endpoint team and the data owners before rules are deployed, so that alert volume and retention decisions are made deliberately rather than discovered after deployment.
Telemetry sources that reveal clipboard access on each platform
This table maps the telemetry that can reveal clipboard access for T1115 Clipboard Data on Linux, macOS and Windows to the signal to look for and the open-source collector that gathers it. Read each row as a question to answer in your own environment: does the collector on this platform record the signal, and can your analysts query it? The main takeaway is that process-level telemetry gives the strongest starting point, while clipboard-specific visibility usually needs extra collection that you must confirm and test.
| Telemetry source | Signal to look for | Platforms covered | Open-source collector |
|---|---|---|---|
| Process Creation (DC0032) | Unexpected processes launched from user sessions that invoke clipboard utilities or scripting interpreters, with parent-child relationships and command-line arguments recorded | Linux, macOS, Windows | Wazuh agent, Sysmon-style logging via Wazuh on Windows, Velociraptor for on-demand process queries |
| Process Access (DC0035 or the ATT&CK Process Access data component) | Access to processes that hold clipboard contents or interactive desktop sessions, especially reads of memory or handles from non-interactive accounts | Windows | Sysmon-style logging via Wazuh, Velociraptor hunts over process handle artifacts; confirm current data component ID in the ATT&CK version you target |
| Command Execution (DC0064) | Shell or script activity that reads or writes clipboard buffers through built-in clipboard commands, recorded in shell history or script logs | Linux, macOS | Wazuh agent log collection of shell history and audit records, Velociraptor artifact collection |
| File Creation (DC0039) | Temporary files written to user or temp directories that hold captured clipboard text, followed by outbound transfer or archiving | Linux, macOS, Windows | Wazuh file integrity monitoring on defined user and temp paths, Velociraptor file hunts |
| Network Traffic Content (DC0085) | Outbound content that matches staged clipboard data, typically visible only where inspection of unencrypted or decrypted traffic is permitted | Linux, macOS, Windows | Zeek for protocol-level metadata, Security Onion or Suricata for signature matches, subject to your inspection policy |
| Network Connection Creation (DC0082) | New outbound sessions from hosts or accounts that do not normally send data to the destination, following a clipboard-related process launch | Linux, macOS, Windows | Zeek connection logs, Wazuh correlation of endpoint and network events |
| Module Load (ATT&CK data component, confirm ID) | Loading of libraries tied to clipboard or GUI session APIs by processes that do not normally use them | Windows | Sysmon-style logging via Wazuh, Velociraptor artifact collection |
Detection logic to build for clipboard collection
Clipboard collection rarely leaves one clear signal, so the detections below work as a set. Each card examines a different piece of evidence: the program that reads the clipboard, the process that launched it, the process that owns clipboard state, and what is normal for the host. Tune each one against your own baseline and allowlist legitimate tools before you judge alert volume.
Unexpected clipboard utilities
Start with process creation events for programs whose main job is to read or write the clipboard. These include command-line clipboard helpers on Linux, macOS and Windows, and PowerShell clipboard functions run from a script host. Alert when one of these runs on a host or under a user where it has not appeared in your baseline, or under a service account. The key question is whether a person or documented job needed that helper at that time. Record the parent process, signer and file hash so analysts can separate a one-off from a pattern.
Clipboard reads from unusual parents
Lineage often matters more than the binary name. Flag clipboard readers launched by document viewers, mail clients, browsers, script interpreters or scheduled tasks, especially when the parent has no interactive window or runs from a user profile directory. Alert on a new parent-child pair for a known clipboard tool within a host role. Correlate with network connection events for the same process tree, because a clipboard reader that then sends data outbound deserves higher priority.
Cross-process access to clipboard owners
Process Access telemetry shows one process opening another with a set of rights. Watch for non-system processes that open the processes that hold clipboard state, such as the Windows desktop shell, remote desktop clipboard redirection components, clipboard manager agents, and display server or clipboard daemon processes on Linux and macOS. Flag access rights that exceed the caller's documented role. Confirm in a test environment which access details your EDR records, because coverage varies by product.
Per-role baselines for host types
Build separate baselines for developer workstations, kiosks, shared terminal servers, virtual desktop pools and servers. A clipboard helper that is routine on a developer laptop may be unexpected on a server, and clipboard reads on a kiosk should be rare to none. Set starting thresholds from the observed normal rate for each role over a window you choose, then alert when a deviation persists across several consecutive windows. Review thresholds after each major change to the host image.
Allowlist known clipboard tools
Clipboard managers, remote desktop clients, password managers and IT management agents will generate most early alerts. Build allowlist entries keyed on signer, install path and expected parent, not on process name alone, because names are easy to copy. Review each entry when the agent is upgraded or the image changes. Ask each vendor which of its processes touch the clipboard and under what conditions, then record the answer in your change records so the allowlist can be audited.
Confirm telemetry before trusting silence
A quiet dashboard proves little until you know what is logged. Confirm which events your Wazuh agents, Sysmon configuration, audit rules or macOS unified logging capture for clipboard helper execution and cross-process access, and document the gaps. Test each detection with benign, documented clipboard activity in a private cyber range before relying on it. Record the ATT&CK version your mappings target, because detection content changes between releases.
How to validate the detection before you trust it
This sequence proves that the T1115 Clipboard Data detections fire on the intended behavior, on each platform in scope, and that they still match after the ATT&CK version changes. The output is a dated validation record that the detection owner can defend in front of an auditor or incident review board.
Confirm the ATT&CK version and scope
The detection owner records the ATT&CK version the rules target, the Clipboard Data technique and any sub-techniques in that version, and the platforms in scope (Linux, macOS and Windows). Check the current technique page and its detection strategy against the ATT&CK updates pages before writing the test plan, because releases can rename, deprecate or revoke techniques. Done when the scope note names the version and the rule IDs it covers.
Define benign and malicious-style scenarios
The purple team lead writes a short scenario list. Each entry describes a clipboard access pattern in words, such as a user-initiated paste into an approved application (benign baseline) and a non-interactive process reading clipboard contents from an unexpected parent process (malicious-style). Each scenario states the expected outcome: alert, no alert, or alert with a specific severity. Done when every scenario has a documented expected result that a reviewer can check without reading the rule.
Map scenarios to platforms and telemetry
The detection engineer lists which telemetry source supports each scenario on each platform, for example process creation and process access events on Windows, and the equivalent process telemetry collected on Linux and macOS through the agent or audit configuration in place. Where a platform lacks the telemetry for a scenario, the gap is recorded as a coverage finding, not silently skipped. Done when a coverage matrix shows each scenario, platform and data source, with gaps marked.
Run emulations in the cyber range
The red team or the purple team operator executes each scenario in the private cyber range, with the range clock synchronized across hosts and the run identifier written into the test record. The operator runs each scenario on a clean host state where possible and repeats runs so that results are not based on a single event. Done when every planned run has a start time, end time, host, platform and run identifier logged.
Record alerts, timing and false positives
The analyst checks the SIEM, for example Wazuh alerts, for each run and records whether the expected rule fired, the rule ID and version that fired, the time from the event to the alert, and any unrelated alerts raised during the same window. Timing is measured from the event timestamp in the telemetry to the alert timestamp, not from the operator's keystroke. Done when each run has a row showing fired or not fired, the latency observed, and the false positive count.
Judge results against the expected outcomes
The detection owner compares each run record with the expected outcome from the scenario list and classifies the result as a pass, a missed detection, an unexpected alert or a telemetry gap. Each missed detection gets a root cause and a tuning or telemetry ticket. Done when the validation record shows a decision for every scenario and platform, signed off by the detection owner.
Re-test after each ATT&CK version change
When a new ATT&CK version is released, the detection owner compares the technique, detection strategy and data component references against the supplied STIX bundle for the target version, then reruns the affected scenarios. A rule that still matches but is mapped to a changed or deprecated reference is updated and re-validated. Done when the record shows which ATT&CK version was tested, which rules changed and which scenarios were rerun.
Preventive controls that reduce clipboard exposure
ATT&CK maps several mitigations to clipboard collection, but none of them stops a process on a user's session from reading the clipboard. The controls below reduce how often sensitive data lands on the clipboard, how quickly misuse is noticed, and how much privilege a compromised session has. Treat each one as partial and confirm its effect in your own environment.
User training for clipboard hygiene
User Training (M1017) is the ATT&CK mitigation most directly tied to reducing how often sensitive values sit on a clipboard. Staff who handle credentials, customer identifiers or key material can be taught to use password managers with autofill, to avoid copying secrets into chat or email, and to report unexpected clipboard prompts or tools. This is a partial control: training changes habits but cannot stop malware running under a logged-in user. Confirm in your own environment which roles handle the most sensitive copy operations and whether those roles receive targeted guidance rather than a generic module.
Least privilege for user accounts
User Account Management (M1018) limits what a compromised account can reach. Clipboard collection usually runs in the context of the logged-in user, so the practical question is which accounts can install software, load drivers or run scripts with broad permissions. Reviewing local administrator membership, restricting application allowlisting for privileged sessions and separating administrative accounts from daily-use accounts shrink the set of processes that can read clipboard content. Confirm whether your endpoint management tool enforces these restrictions or whether they depend on local settings users can change.
Audit logging for clipboard-adjacent activity
Audit (M1047) covers the logging needed to see clipboard-related activity after the fact. Process Creation and Process Access events, collected from Windows, Linux and macOS endpoints, show which processes start and which open handles to other processes. Clipboard access itself is often not logged directly, so audit coverage is a detection aid rather than prevention. Confirm that process telemetry is forwarded to your central platform, that retention meets your investigation needs and that someone reviews alerts from it.
Clipboard limits in managed browsers and apps
Some organizations reduce clipboard exposure through application settings, such as disabling clipboard sync between devices or restricting copy operations in remote desktop and virtual desktop sessions. The ATT&CK mitigations supplied for this page do not cover these settings directly, so treat them as local policy choices. Confirm which applications in your estate support such settings, whether vendor documentation describes them, and whether business users can override them. Test changes with a small group before wider rollout.
Triage steps when a clipboard collection alert fires
Start by confirming what the alert actually describes, because clipboard collection detections on Linux, macOS and Windows often fire on legitimate software such as password managers, remote desktop helpers and clipboard history utilities. Walk the process lineage first: identify the parent process, the full image path, the binary's signer or package origin, and whether the clipboard reader was started interactively or by a service or scheduled job. Then check the user and session. Confirm that the account is the expected owner of the workstation, that the session is local or remote as expected, and that the logon time fits the user's normal pattern. An interactive user running a known utility from its usual path is a very different case from a service account reading the clipboard at 3 a.m. Agree the approved tool inventory with the endpoint team before an incident, so the analyst can answer the approval question from a list rather than from memory.
Next, preserve volatile evidence before anything changes on the host. Velociraptor or a comparable endpoint collection tool can capture the process tree, running binaries with hashes, open network connections and loaded modules while the process is still alive. Ask that the collection include the parent chain and any child processes started after the alert, because clipboard readers are often short-lived and leave little on disk. Then scope the fleet: search every host for the same binary hash, the same path and the same parent-child pattern across the retention window. A single unapproved binary on one workstation may be an isolated mistake, but identical execution on several hosts points to a shared tool or a campaign. Record each query and its time range so the hunt can be repeated. Confirm which Velociraptor artifacts and retention settings your deployment provides before you rely on them during an incident.
Decide on containment against escalation criteria set in advance. Escalate immediately when the binary is unapproved or unsigned, the session belongs to a privileged or service account, the clipboard reader runs alongside credential access or archive activity, or the host handles regulated data. In those cases, isolate the host at the network layer and suspend the account while the investigation continues. For a confirmed approved tool used by the expected user, close the alert and record the reason. Document every outcome in the case record: the disposition, where the evidence is stored, the affected hosts, the ATT&CK version the rule maps to (the pages in this series target Enterprise ATT&CK 20.0), and any tuning change, such as an allowlist entry with a named owner and a review date. These notes are what allow the next analyst to judge a similar alert quickly and safely.
Rehearsing clipboard detection in a private cyber range
The Linux range is a private, isolated set of hosts built for this exercise only, with no connection to production identity or data. Each host runs an agent that forwards process telemetry to a test Wazuh or Security Onion deployment, and the range team confirms that process creation events include parent process, user and command context before any inject runs. The scenarios are illustrative and should be adapted to the environment the client actually operates.
- Range environment: A small set of desktop-style Linux hosts with a graphical session, a clipboard utility present in the image, and synthetic credentials placed in the session only.
- Injects: A scripted activity that reads clipboard contents through a user process, followed by a variant that runs the same action from a non-interactive shell.
- What good detection looks like: An alert tied to process creation that names the clipboard utility, the parent process and the user, mapped to the ATT&CK version the team targets.
- What good response looks like: Analysts triage within the agreed window, pivot to the host timeline and record whether the activity was expected for that user.
- Gap check: Confirm which clipboard tools are not logged by default and document the detection gap.
Before closing the exercise, check that every inject produced a logged event and that the alert text is clear enough for a second analyst to act on.
The macOS range uses managed test endpoints enrolled in a private management tool, with unified logging and endpoint telemetry forwarded to an open-source SIEM. The range team confirms which log categories are available on the image version in use, because coverage differs by OS release and by agent configuration. Scenarios are illustrative and must be validated against the client's own endpoint build.
- Range environment: Standard user accounts on test hardware, a set of synthetic documents and credentials open in common applications, and no production sign-in.
- Injects: A user-level process that accesses pasteboard contents, followed by a variant launched from a scheduled job to test off-hours activity.
- What good detection looks like: Process creation and process access events correlated to the user session, with a rule that flags access by unexpected binaries.
- What good response looks like: Analysts confirm the binary's signature and location, check the user's recent activity and decide whether to isolate the endpoint.
- Tuning check: Measure how many benign developer tools trigger the same rule and add documented exclusions where justified.
Record the log categories that were absent during the exercise, and ask the endpoint vendor to confirm which events are available on your OS version.
The Windows range uses domain-joined test workstations with Sysmon-style process and access telemetry and Windows event forwarding into a test Wazuh or Security Onion stack. Because process access events can be noisy, the range team agrees a baseline of normal clipboard-adjacent activity before the injects begin. Scenarios are illustrative and must reflect the client's own policy and build.
- Range environment: Test workstations with a logged-on synthetic user, an isolated test domain and no trust relationship to production.
- Injects: A process that reads clipboard contents from a user session, a second run from a service context, and a third run that reads clipboard data just before a file is written to a staging folder.
- What good detection looks like: A process access event combined with process creation context that identifies the reading process, its parent and its session, mapped to the relevant detection strategy.
- What good response looks like: Analysts isolate the session if the activity is unexpected, preserve the process tree and hand off to the incident lead with the timeline.
- Noise check: Compare alert volume against the baseline and tighten rules that fire on approved tooling.
Confirm the telemetry configuration in the test domain matches the production configuration, because a mismatch makes the exercise results misleading.
Clipboard detection depends on three roles working together: SOC analysts who triage alerts, detection engineers who write and tune rules, and incident leads who decide on containment. The cyber range lets each role rehearse its own step, so handoffs are tested before a live event. The scenarios are illustrative, and the client should agree the role split and escalation paths in writing before the exercise begins.
- SOC analysts: Receive a realistic-looking alert in the range queue and document triage steps, including the questions asked of the user.
- Detection engineers: Review the rule logic against the injects, record false positives and propose changes through the normal change process.
- Incident leads: Decide on containment, communication and evidence preservation, and confirm the decision log is complete.
- Shared checks: Verify that each alert links to the ATT&CK technique and the data components used, so the mapping stays accurate across releases.
- Debrief: Record gaps, owners and due dates in the exercise report.
At the end of the exercise, check that every role can name its next action without consulting the range team.
Questions detection engineers ask about T1115
How do I separate clipboard managers from malicious clipboard readers?
Start from behavior and lineage, not from the fact that a process touches the clipboard. Clipboard managers, remote desktop tools, password managers and developer utilities legitimately read clipboard contents, so a clipboard read alone is weak evidence. Build an allowlist from software inventory, record the parent process, signing identity and install path, and then alert on clipboard access from processes outside that baseline or from unsigned binaries launched from user-writable directories. Pair this with what the process does next, such as writing to disk or opening a network connection, because a benign reader rarely does both. Confirm exactly which process-level fields your Wazuh, Velociraptor or EDR telemetry exposes before writing rules that depend on them.
Is process access telemetry enough to detect clipboard data on macOS?
Usually not on its own. Process access and process creation events show which binaries were started and which processes interacted with others, but clipboard reads on macOS may not produce a distinct event in every logging configuration, so you should confirm what your endpoint agent and unified logging actually record. Treat process telemetry as one signal and combine it with process lineage, code signing status and any network activity from the same process. Validate coverage in your cyber range by running a known benign clipboard utility and checking which fields appear in your SIEM before you trust a detection. Document the gaps as residual risk.
How should we handle ATT&CK version changes when maintaining T1115 detections?
Name the ATT&CK version your detection mappings target, and record it in every rule's metadata. MITRE publishes ATT&CK releases on a regular cycle, and releases can rename, deprecate or revoke techniques and change the data components that detection strategies reference. Check the update notes for each release and compare the technique's data components against your current telemetry sources. Keep a short change log in your detection repository so an auditor or analyst can see which mapping was valid when an alert fired. Review the mapping whenever your ATT&CK baseline moves forward.
How do we tune clipboard detections for noisy developer workstations?
Developer machines run many scripts, IDE plugins, terminal multiplexers and secret-handling helpers that touch the clipboard, so a broad rule will flood the queue. Tune in three steps: scope the rule to hosts and user groups where clipboard reads are unexpected, suppress known developer tool signatures with documented exceptions that expire, and require a second signal such as an unsigned binary, an unusual parent process or outbound traffic before raising severity. Review suppressions quarterly and record who approved each one. Measure false positives during a cyber range exercise with realistic developer tooling before you deploy the rule to production.
Which data sources should we enable first for T1115 detection?
Prioritize process creation telemetry, process access where your platform records it, and command execution logs from endpoints that handle sensitive work, such as finance, engineering and administrative workstations. Process creation gives you lineage and binary paths, which are essential for triage. Add file creation events only where the malicious reader is expected to write staging data, and confirm that your agent does not generate excessive volume before enabling it broadly. Ask your EDR or logging vendor which event types cover clipboard activity on each operating system, because coverage differs between Linux, macOS and Windows.
Can our own team run a T1115 detection program without outside help?
Yes, if you have an endpoint telemetry pipeline, a SIEM or log platform, someone who can write and test detection rules, and time to rehearse them. The work splits into telemetry onboarding, rule authoring, validation in a test environment, response runbooks and periodic tuning. Many teams find the validation and tuning steps take the most effort because they need controlled test activity that does not disrupt users. A fixed-scope engagement from DeployOpen can cover planning, implementation on open-source tooling in your environment, and cyber range rehearsal, with the scope and deliverables agreed in writing before work starts.
What should we ask a provider before they build T1115 detections for us?
Ask which ATT&CK version the detections target, which telemetry sources they depend on, and how they will validate coverage on each operating system in your estate. Request a list of what is in scope and what is excluded, including whether macOS and Linux endpoints are covered. Ask how false positives will be measured, who owns the rules after handover, and how response runbooks will be tested in a cyber range. Also confirm the timeline and deliverables in writing. Any quote should follow from that written scope, and you should check it against what your own environment already logs.
How DeployOpen builds clipboard detections and range scenarios
DeployOpen builds a clipboard detection for T1115 by starting from the platform's own telemetry, not from a generic rule. In a client's self-hosted stack, the first step is an inventory of which endpoints, operating systems and agents actually produce process and access events, because a clipboard rule is only as good as the events beneath it. On Windows, that usually means confirming that process creation and process access events reach the SIEM with enough fields to show the calling process and the target. On Linux and macOS, the team confirms which display or clipboard helper processes run on user workstations and whether their launches are logged. The output is a written coverage statement that the client can challenge before any rule goes live.
Purple team exercises follow the same logic in a private cyber range that mirrors the client's operating systems, endpoint agents and logging pipeline. DeployOpen's security testing practice runs the exercise jointly with the client's detection engineers, who watch the alerts as they fire. The team records which behaviors were observed, which were missed, and which benign processes generated noise, then tunes the rule and reruns the same scenario. Because ATT&CK changes between versions, each detection mapping should name the ATT&CK version it targets. Clients should confirm the version in the Enterprise ATT&CK release notes at the time of the engagement, and ask the team to document any technique renamed or deprecated since the last review.
Range scenarios are scoped in writing before work starts, with the client approving the accounts, endpoints and test windows used. Clients should ask for the scenario inventory, the success criteria for each detection, the rollback steps for any test artifact, and the evidence package that comes out of the exercise, including the rule versions tested. Ongoing retesting, for example after an agent upgrade or a change in endpoint policy, is typically handled as a retainer rather than a one-off project. DeployOpen prepares this evidence for internal reviews and for compliance assessors, but it does not issue audit reports or certifications, which remain the responsibility of independent auditors.
