Mobile T1513 Screen Capture: Detecting and Blocking Screen Theft on Android

Mobile malware that can see the screen can read whatever the user reads, including one-time codes, balances and messages that never touch storage. MITRE ATT&CK for Mobile tracks this as T1513 Screen Capture, a Collection technique. ATT&CK v20 lists it for Android only. This guide explains the three capture routes ATT&CK describes, the Android controls that shut each one, what managed-device and app-vetting telemetry can show, and how app teams protect sensitive screens. It is written for mobile security engineers, MDM administrators and detection teams. For the wider matrix, see the MITRE ATT&CK for Mobile Guide.

Key takeaways

• Three routes, three controls. ATT&CK names the MediaProjection API, accessibility services, and root or adb access to the screencap and screenrecord commands; each needs a different control.
• Accessibility is the quiet route. MediaProjection needs per-session consent and shows a status bar indicator on recent Android, so most banking trojans in the ATT&CK procedure list read the screen through an accessibility service instead.
• Allow-listing beats user warnings. On managed Android, permittedAccessibilityServices, screenCaptureDisabled and locked developer settings close the routes for work data without relying on the user.
• App teams own the last line. FLAG_SECURE on sensitive screens blanks background screenshots and casts; Android's own guidance says it is not a complete defence, so pair it with server-side transaction checks.
• iOS is not listed. ATT&CK v20 does not list T1513 for iOS; treat iOS screen-capture risk under spyware response rather than this technique.

What T1513 covers and how it works

ATT&CK defines Screen Capture as collecting information from the device screen, such as the foreground app, user data or credentials. The technique description gives three routes on Android:

The Android MediaProjection documentation adds detail that matters to defenders: from Android 14 a projection token can create only one virtual display, so reuse throws a SecurityException and a new consent is needed per session; apps targeting Android 14 must also declare a mediaProjection foreground service type. Android 14 QPR2 added app screen sharing, which lets the user share one app window, excluding notifications and system bars. Android 15 hides notification content and password input from remote viewers during screen sharing. These changes raise the cost of the MediaProjection route, which is why the accessibility route dominates the procedure examples.

Real cases from ATT&CK procedure examples

ATT&CK v20 maps 27 software entries to T1513 (26 malware families and one commercial monitoring tool). A representative set, as ATT&CK and its cited reports describe them:

The pattern is consistent: capture is aimed at the moment of authentication or payment, and accessibility does most of the work. That links T1513 closely to Android Banking Trojans Guide material and to the sibling technique Mobile T1517 Access Notifications, which takes the same codes from notifications instead of the screen.

Prevention on managed Android

ATT&CK lists three mitigations for T1513: M1012 Enterprise Policy, M1011 User Guidance and M1013 Application Developer Guidance. Enterprise policy does the heavy lifting. In the Android Management API the relevant policy fields are:

• screenCaptureDisabled: disables screen capture on the managed device or profile; Google notes it also blocks Circle to Search, so warn users before rollout.
• permittedAccessibilityServices: an explicit package list of accessibility services the user may enable. If the field is not set, any accessibility service can be used. ATT&CK's mitigation names the equivalent DPC method, DevicePolicyManager.setPermittedAccessibilityServices.
• advancedSecurityOverrides.developerSettings: replaces the deprecated debuggingFeaturesAllowed field; keep developer settings off so adb and USB debugging cannot be turned on outside development devices. See the Android Platform Tools and ADB guide.
• advancedSecurityOverrides.untrustedAppsPolicy and googlePlayProtectVerifyApps: block sideloading and keep Play Protect app verification enforced, so apps outside Play review cannot be installed.

On unmanaged or personally owned devices, Android 13 and later apply restricted settings: a sideloaded app cannot be granted accessibility access until the user goes to the app's info screen and chooses "Allow restricted settings". User guidance (M1011) should name that screen explicitly: a request to allow restricted settings for an app that is not an accessibility tool is a strong warning sign. Google Play's AccessibilityService policy limits the isAccessibilityTool flag to apps that help people with disabilities and requires a prominent in-app disclosure for other uses, which helps vetting teams separate legitimate requests from suspicious ones.

For high-risk users, Android Advanced Protection bundles several of these restrictions. For the general enterprise baseline, see the Android Enterprise Security Guide.

Protecting sensitive screens in your own apps

M1013 asks developers to set FLAG_SECURE on sensitive screens. Android's fraud prevention guidance describes what it buys and where it stops:

Because no client control is complete, the stronger design removes the value of a captured screen: confirm high-value actions out of band, bind approvals to the transaction details, and avoid showing full one-time codes or recovery secrets on screen longer than needed. The OWASP MASVS-PLATFORM category explicitly covers leakage of sensitive data through auto-generated screenshots, and the Mobile App Security Testing Guide shows how to test for it.

Detection and measurement

ATT&CK's detection strategy for T1513 (Detection of Screen Capture) correlates three evidence types, treating management state as periodic observation rather than real-time events:

• Permission state: grant state and requested permissions from the DPC or app vetting, for example an app holding accessibility or media projection related declarations it does not need.
• Application state: managed package inventory and metadata from Android Enterprise or the EMM, to catch new or unapproved packages.
• Runtime API traces: from instrumented dynamic analysis in app vetting, a MediaProjection session, accessibility observation of another foreground app, or a screencap or screenrecord call while a different app is in front.

Mobile threat defence agents typically surface the same signals as risky-app or risky-configuration alerts; see the Mobile Threat Defense Buyer's Guide for what to ask of them. Useful metrics:

1. Percentage of managed Android devices with a non-empty accessibility allow list enforced.
2. Count of devices with developer settings or USB debugging enabled, outside named development devices (target zero).
3. Number of installed apps holding an enabled accessibility service that is not on the allow list, trended weekly.
4. Share of the organisation's own sensitive screens with FLAG_SECURE verified in release testing.
5. Median time from an MTD risky-app alert to device quarantine.

Response when capture is suspected

1. Contain: move the device to a non-compliant state so conditional access blocks corporate apps, and revoke active sessions and refresh tokens for the user, since anything shown on screen should be treated as exposed.
2. Preserve: capture the MDM app inventory, accessibility grants and MTD alert before wiping. For suspected spyware on high-risk users, take a consensual forensic acquisition with the Mobile Verification Toolkit (MVT), which supports Android and iOS.
3. Reset credentials: rotate passwords and re-enrol authenticators for any account used on the device during the exposure window; re-issue any API keys or recovery codes that were displayed.
4. Eradicate and recover: factory reset and re-enrol; confirm the allow list and developer settings policy are applied before returning the device.

The full sequence is in the Mobile Spyware Infection Response Playbook.

Where identity fits

Screen capture targets identity artefacts more than files: authenticator codes (as in the Crocodilus case), SMS codes, passwords typed into banking apps, and, for developers and administrators, API keys and tokens shown in consoles or mobile admin apps. Prefer phishing-resistant authenticators that do not display a code, and never show long-lived machine credentials on a mobile screen. See the Authenticator Apps and OTP Guide.

Framework mapping

Common failure patterns

• Leaving the accessibility allow list unset: an unset permittedAccessibilityServices field means any service can be enabled, which is the route most families use.
• Blocking screenshots but not accessibility: screenCaptureDisabled does not stop an accessibility service reading text from views.
• Treating FLAG_SECURE as complete: Android itself says it is not reliable against overlays and older devices; transaction signing still matters.
• Developer settings left on: test or shared devices with USB debugging enabled give anyone with brief physical or adb access a capture route.
• Codes on screen: flows that show a full one-time code or recovery secret on screen give capture malware exactly what it is built to steal.

Practitioner checklist

• Set permittedAccessibilityServices to an explicit allow list on every managed Android device or work profile.
• Enable screenCaptureDisabled where work data is sensitive, after warning users about Circle to Search.
• Disable developer settings and USB debugging through advancedSecurityOverrides.developerSettings.
• Block untrusted app sources and enforce Play Protect verification.
• Add accessibility and media projection use to your app vetting criteria, with dynamic analysis for unknown apps.
• Set FLAG_SECURE and HIDE_OVERLAY_WINDOWS on login, payment and code-display screens in your own apps, and test them.
• Train users that "Allow restricted settings" for a non-accessibility app is a red flag.
• Rotate credentials and tokens used on any device where capture is suspected.

Standards and references

• MITRE ATT&CK: Screen Capture (Mobile T1513)
• Android Developers: Media projection
• Android Developers: Secure sensitive activities
• Android Developers: Android 15 behaviour changes for all apps
• Google: Android Management API policies reference
• Google Play: Use of the AccessibilityService API
• OWASP: Mobile Application Security Verification Standard
• Mobile Verification Toolkit documentation

Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · Mobile App Permissions · Android Banking Trojans Guide · Mobile Device Management Security Guide · Mobile T1516 Input Injection