Detecting and Mitigating Screen Capture (T1113)

Screen Capture (T1113) is a collection technique in MITRE ATT&CK. MITRE lists Linux, macOS and Windows.

A screenshot can show what a user is looking at: documents, chat windows, admin consoles, even credentials that a user is typing into a visible field. For an attacker already on a host, it is a cheap way to see what matters.

How attackers use it

MITRE describes adversaries taking screen captures of the desktop to gather information over the course of an operation. The capability may be built into a remote access tool used after compromise. It is also usually possible through native utilities or API calls, and MITRE names CopyFromScreen, xwd and screencapture.

Because the capture can use functions that ship with the OS, no special malware is required, and the resulting image files are small and easy to move out.

How to detect it

MITRE's strategy is Detect Screen Capture via Commands and API Calls. Analytics describe:

• Windows: unusual use of screen capture APIs such as CopyFromScreen, or command line tools, that write image files to disk.
• macOS: use of the built-in screencapture command, or undocumented APIs, from suspicious parent processes.
• Linux: tools such as xwd or import producing screenshots, especially under non-GUI parent processes.

The thread is context. A screenshot taken by a person pressing a key is normal. A screenshot from a service, a script or a process with no user session is not.

Telemetry to use:

• Process creation logs with parent and command line, which show screencapture, xwd or import being run by an unexpected parent.
• File creation events for image files in temp or hidden directories, such as Sysmon event ID 11 on Windows.
• Endpoint tool alerts for processes calling screen capture APIs.
• On macOS, the Screen Recording permission list, which shows which applications have been granted access.

Repeated captures at fixed intervals, followed by compression and an outbound transfer, are a strong combined signal.

How to reduce the risk

MITRE does not list a formal mitigation for this technique, so the steps below are general practice:

1. Limit which applications may capture the screen. On macOS, review and prune the Screen Recording permission and use device management to control it.
2. Use application control so unapproved tools cannot run.
3. Restrict remote access tools to approved ones.
4. Reduce what can be captured: lock idle sessions, and avoid showing secrets on screen during admin work.

Check your own environment

• Do your endpoint logs show command lines for screen capture utilities?
• On Macs, which apps hold Screen Recording permission today? You can see this in System Settings under Privacy and Security.
• Are remote access tools limited to an approved list?
• Do you alert on image files created in unusual folders by non-interactive processes?

What a screenshot can leak

It helps to think about what is typically on a screen during work. Chat conversations, tickets, admin consoles, dashboards, password manager windows and documents under review are all common. A capture also includes anything shown by a remote session or a virtual desktop.

That is why the technique appears in many intrusions as a quick way to learn about a user and an environment without searching the file system. It is also why repeated captures can be valuable: they show change over time, such as a user logging in to a system.

For defenders, the useful reminder is that this technique needs no special access beyond the user's own session. Limiting what runs in that session, and what it is allowed to reach, is the lever you have. Pair that with logging that records which process wrote image files, and you can answer the question that matters after an incident: what did the attacker see?

Quick check

Sources

• MITRE ATT&CK, Screen Capture (T1113)