MITRE ATT&CK T1113 Screen Capture: Detecting Data Gathering

A screenshot collects whatever the user can see: the open email, the finance system, the password reset page, the admin console with a token on screen, all without touching the underlying data stores or their access controls. MITRE ATT&CK T1113 Screen Capture, in the Collection tactic (TA0009), covers adversaries taking screen captures of the desktop during an operation, through remote access tool features, native utilities or API calls such as the .NET CopyFromScreen method, xwd on Linux and screencapture on macOS. ATT&CK v20 lists Linux, macOS and Windows as platforms, no sub-techniques, and no mitigations, stating that the technique cannot be easily mitigated with preventive controls because it abuses system features. That makes detection and limiting what is on screen the main levers. This guide is for detection engineers and endpoint teams; for presenter and meeting hygiene, see Screen Sharing Security.

Key takeaways

• No ATT&CK mitigation exists. T1113 relies on ordinary operating system features, so your controls are detection, operating system permission gates where they exist (macOS Screen Recording), and reducing sensitive content on screen.
• It is built into most remote access malware. ATT&CK lists dozens of families and groups with screenshot capability, from Agent Tesla to Gamaredon Group tooling that captures the screen every minute.
• Legitimate remote tools do it too. ATT&CK records GOLD SOUTHFIELD using ConnectWise remote monitoring and management to capture screens, so governing remote tools is part of this technique.
• Detect the pattern around the capture. ATT&CK's DET0346 looks for screen capture APIs or tools used by unusual processes, especially non-GUI parents, and image files written to disk; periodic image writes followed by outbound transfer are the strongest signal.
• Capture exclusion is not a security boundary. Windows can exclude a window from capture, but Microsoft states that this is not a security feature and offers no guarantee.

What the technique covers

Screenshots give adversaries context they cannot easily get from files: what the user is working on, which systems they use, what a payment or approval screen looks like, and sometimes secrets displayed in plain text. Screen capture often sits beside keylogging (T1056 Input Capture), clipboard collection (T1115 Clipboard Data) and video capture (T1125 Video Capture) in the same malware, and its output is usually staged locally (T1074) and exfiltrated over the command and control channel.

On macOS, the permission model is covered in detail in the macOS TCC and Privacy Permissions Management Guide. Adversaries who cannot get approval may try to manipulate TCC itself, which ATT&CK tracks separately as T1548.006 TCC Manipulation.

How adversaries use it: cases from ATT&CK

• Volt Typhoon (G1017): obtained a screenshot of a victim system using the gdi32.dll and gdiplus.dll libraries, citing CISA advisory AA24-038A. A living off the land actor using native libraries rather than a dedicated tool shows why process context matters more than tool names. See the Volt Typhoon Threat Actor Profile.
• VOID MANTICORE (G1055): captured screen content during an active Zoom session, citing an FBI IC3 flash from March 2026.
• GOLD SOUTHFIELD (G0115): used the ConnectWise remote monitoring and management tool to obtain screen captures. See MITRE ATT&CK T1219 Remote Access Tools.
• FIN7 (G0046): captured screenshots and desktop video recordings, citing the US Department of Justice.
• Gamaredon Group (G0047): malware that takes screenshots of the compromised computer every minute.
• 2025 Poland Wiper Attacks (C0063): the adversaries captured screenshots of devices using the NirSoft nircmd console utility.
• Kimsuky (G0094): captured browser screenshots using the TRANSLATEXT browser extension (S1201).
• Agent Tesla (S0331): ATT&CK records that it can capture screenshots of the victim's desktop.

What to detect and where

ATT&CK v20 detection strategy DET0346, Detect Screen Capture via Commands and API Calls, has three analytics:

Rules that work in practice

• Periodic image writes: a process writing PNG, JPG or BMP files to temp, AppData or hidden directories at regular intervals, especially a process that is not a known screenshot, conferencing or support tool. File creation telemetry (for example Sysmon Event ID 11) supports this.
• Capture then send: image files created and then read by a process that opens an outbound connection, compressed into an archive, or deleted shortly after. This links T1113 to staging and exfiltration.
• Script hosts and services capturing: PowerShell, script hosts, services or processes running without an interactive desktop loading graphics libraries such as gdiplus.dll or invoking CopyFromScreen. Use targeted Event ID 7 filters, because logging every image load is noisy.
• macOS permission activity: Screen Recording approval requests or grants for unexpected apps, seen in the com.apple.TCC unified log subsystem, and screencapture launched from launch agents, shells spawned by documents or unsigned binaries.
• Linux: xwd, import or similar tools executed by web server, cron or service accounts, or over SSH sessions to hosts with a desktop.
• Remote tool screen sessions: new or unapproved remote monitoring and management agents, and screen sessions opened outside change or support tickets.

Noise and baselining

Many legitimate products capture screens: conferencing, remote support, screenshot tools, user experience analytics, some DLP and employee monitoring software, and accessibility tools. Inventory them by signed publisher and path, allowlist on that basis, and alert when an allowlisted tool runs from an unusual path or is launched by an unusual parent. Any new screen-capturing product should go through the same approval route as other software that can see sensitive data.

Reducing exposure

Because ATT&CK lists no mitigation for T1113, the measures below are NHI Mgmt Group recommendations. They limit what a screenshot can reveal and who can take one.

• Use the macOS gate: keep Screen Recording permission tied to an approved app list, deny it by profile for apps that should never hold it, and review holders regularly.
• Control remote access tools: allow only approved remote support tools, require session approval by the user where the product offers it, and log every session.
• Keep secrets off screen: mask secrets, tokens and API keys in admin consoles by default, show them once on creation, and prefer copy buttons with automatic clearing over displaying values in full.
• Isolate sensitive work: run administrative sessions from privileged access workstations or isolated remote sessions, so malware on an everyday workstation never sees the admin console.
• Treat capture exclusion as defence in depth: applications can call SetWindowDisplayAffinity with WDA_EXCLUDEFROMCAPTURE (Windows 10 version 2004 and later) to keep a window out of captures, but Microsoft documents that it is not a security feature, works only with desktop composition, and should not be relied on to protect sensitive content.
• Execution control: application control blocks many capture tools and scripts from running from user-writable paths. See the M1038 Execution Prevention guide.

Where identity fits

Screens often display credentials that the rest of your controls protect: newly created API keys, client secrets, one-time recovery codes, connection strings in configuration screens and tokens in developer tools. A screenshot taken at the wrong moment turns into a valid non-human identity credential without any vault being touched. Show secrets once, mask them by default, rotate any secret that was displayed on a host later found to be compromised, and prefer workload identity federation so there is no long-lived secret to display at all.

How to put it in place

1. Inventory legitimate capture software: conferencing, remote support, monitoring and screenshot tools, with publisher, path and owner.
2. Turn on telemetry: process creation everywhere, targeted image load rules for graphics libraries on Windows, file creation for image types in temp and user directories, the TCC unified log on macOS and auditd execve on Linux.
3. Deploy rules in alert-only mode: start with periodic image writes and capture-then-send, then add script host and non-interactive process rules. Tune for two to four weeks.
4. Tighten permissions: apply macOS PPPC profiles that deny Screen Recording to unapproved apps, and an allowlist for remote access tools.
5. Test: with approval, run a benign test binary or script that captures the screen at intervals and uploads the image to a test endpoint, on each platform, and confirm detection with the process, user and host attached.
6. Promote and roll back: raise severity for tuned rules; if a business tool trips them, add a publisher and path exception with an owner rather than disabling the rule.

Decision guidance

• Endpoint detection or DLP: EDR detection catches malware taking screenshots; endpoint DLP controls focus on users moving content and rarely see malware captures. Use EDR rules for T1113 and DLP for insider scenarios. See the Endpoint DLP Guide.
• Blocking capture tools: blocking every screenshot tool frustrates users and does not stop malware using native APIs. Block from user-writable paths and unapproved remote tools, and detect the rest.
• Small organisations: rely on EDR defaults, an approved remote support tool list and macOS PPPC profiles.
• Large organisations: add custom capture-then-send detections, privileged access workstations for admins and secret masking standards for internal tools.

Measurement

• Remote tool control: number of unapproved remote access agents found per month, trending to zero.
• macOS permission hygiene: share of Macs where Screen Recording holders match the approved list.
• Detection rate: share of authorised capture tests detected on each platform, and time to alert.
• Secret display: share of internal admin tools that mask secrets by default.
• Noise: weekly false positives from capture rules after each tuning cycle.

Common failure patterns

• Assuming nothing can be done: reading "no mitigation" as "no control", and leaving screenshots entirely unmonitored.
• Unmanaged remote tools: several remote support agents installed over the years, none reviewed, any of which can capture screens.
• Allowlisting by name: excluding any process named like a known screenshot tool, which a renamed binary defeats.
• Secrets on display: admin consoles and internal tools that show API keys and connection strings in full every time the page loads.
• Relying on capture exclusion: treating window capture exclusion as protection, when Microsoft documents that it is not a security feature.

Framework mapping

Equivalent techniques exist in other ATT&CK matrices: Mobile T1513 Screen Capture and T0852 Screen Capture for industrial control systems.

Practitioner checklist

• Inventory every approved product that captures screens, by publisher, path and owner.
• Collect process creation, targeted graphics library loads and image file creation telemetry.
• Alert on periodic image writes and on image files that are archived or sent out shortly after creation.
• Alert on script hosts, services and non-interactive processes capturing the screen.
• Deny macOS Screen Recording by profile to apps that should never hold it, and review holders.
• Allow only approved remote access tools and log every session.
• Mask secrets in admin consoles and show new keys once.
• Test detection with an authorised capture-and-upload simulation on each platform.

Standards and references

• MITRE ATT&CK: T1113 Screen Capture
• MITRE ATT&CK: TA0009 Collection
• CISA: PRC State-Sponsored Actors Compromise and Maintain Persistent Access to U.S. Critical Infrastructure (AA24-038A)
• Microsoft Learn: SetWindowDisplayAffinity function
• Microsoft Learn: Sysmon
• NIST: SP 800-53 Rev 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: ATT&CK Collection Tactic Guide, MITRE ATT&CK T1056 Input Capture, T1074 Data Staged, Infostealer Threat Guide.