Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T1513: Screen Capture

Adversaries may use screen capture to collect additional information about a target device, such as applications running in the foreground, user data, credentials, or other sensitive information. Applications running in the background can capture screenshots or videos of another application running in the foreground by using the Android `MediaProjectionManager` (generally requires the device user to grant consent).[1][2] Background applications can also use Android accessibility services to capture screen contents being displayed by a foreground application.[3] An adversary with root access or Android Debug Bridge (adb) access could call the Android `screencap` or `screenrecord` commands.[4][5]

MobileT1513TechniqueObject v1.3 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

Screen Capture on Android matters because it can turn a mobile device into a source of visible business and personal secrets: foreground apps, messages, credentials, banking or wallet data, and other sensitive content. MITRE notes several paths: user-consented MediaProjectionManager use, accessibility service abuse, or screencap/screenrecord through root or Android Debug Bridge access. For leaders, the issue is less “screenshots” and more whether managed mobile devices, high-risk users, and sensitive apps can prevent or reveal unauthorized capture of what users are seeing.

Executive priority

Prioritize this where Android devices are used for privileged access, banking, cryptocurrency, executive communications, regulated data, or incident response workflows. The relationship set links this technique to numerous Android spyware, surveillanceware, information stealers, and banking trojans, making it relevant to mobile security policy, user guidance, application security requirements, and evidence for mobile device governance. Executives should ask whether EMM/MDM policy, accessibility-service control, debugging restrictions, and user training are actually enforced and auditable on corporate Android devices.

Technical view

SOC, mobile security, and IR teams should validate Android-focused visibility for screen capture risk. ATT&CK provides no official detection text for this technique, but a related detection strategy, DET0668 Detection of Screen Capture, is mapped. Practical validation should focus on events and state changes around MediaProjectionManager consent/use, suspicious accessibility-service enablement, root indicators, ADB/debugging exposure, and invocation or artifacts associated with screencap or screenrecord. Because tactics are not specified in the supplied object, detection engineering should anchor logic to the Android platform and observed collection behavior rather than a tactic label.

Likely telemetry

  • Android application permission and consent events related to screen capture or media projection where available
  • Accessibility service enablement, configuration changes, and app/service inventory
  • EMM/MDM compliance state, device policy settings, and managed configuration evidence
  • Android debugging/ADB enabled state and device developer-option posture
  • Root/jailbreak indicators and device integrity signals

Detection direction

  • Confirm whether DET0668 or equivalent mobile detection content is enabled, tested, and mapped to Android devices in scope.
  • Tune for high-risk combinations: newly enabled accessibility services plus sensitive-app use, media projection prompts from unfamiliar apps, ADB enabled on managed devices, or root indicators with screen capture artifacts.
  • Treat user consent as a blind spot: MediaProjectionManager generally requires the device user to grant consent, so telemetry should distinguish legitimate remote support, conferencing, or productivity tools from unexpected background collection.
  • Correlate with the related software context: multiple mapped Android malware families are spyware, surveillanceware, information stealers, or banking trojans, so screen capture signals should be investigated with credential, financial-app, and data-exfiltration hypotheses.
  • Account for false positives from legitimate screen recording, remote assistance, testing, accessibility, and employee monitoring tools; local allowlists and business justification are required.

Mitigation priorities

  • Use enterprise policy through EMM/MDM to restrict risky device behavior where supported, including debugging exposure, unmanaged app installation, and required compliance posture.
  • Provide user guidance so users understand screen-capture consent prompts, risky accessibility-service requests, and why enabling unknown services can expose sensitive app content.
  • Apply application developer guidance for sensitive Android apps, especially those handling credentials, financial transactions, regulated data, or privileged business workflows, so screen exposure risks are considered during secure design and SDLC review.
  • Prioritize mobile controls for executives, administrators, finance users, and other roles whose screens may expose high-value data.
  • Ensure IR playbooks include mobile evidence collection for accessibility abuse, ADB/root state, suspicious apps, and screen capture indicators before wiping or re-enrolling devices.
Analyst notes and limits

The strongest decision value is governance and validation: determine which Android devices can capture sensitive screens, which apps can request or abuse capture paths, and whether SOC/IR teams can see it. The relationship context is broad, including SpyDealer, Exodus, Monokle, FlexiSpy, GolfSpy, Anubis, Ginp, TrickMo, EventBot, DEFENSOR ID, Mandrake, WolfRAT, GoldenEagle, Tiktok Pro, BusyGasper, Drinik, S.O.V.A., TangleBot, Hornbill, and BOULDSPY using this technique. That breadth supports treating screen capture as a recurring mobile surveillance and fraud-enablement behavior, not a niche feature.

ATT&CK supplies no official detection text and no tactic mapping for this object. The platform is Android only in the supplied fields. This take does not assert active exploitation, customer exposure, attribution, or guaranteed detection. Actual coverage depends on local Android version mix, EMM/MDM capabilities, mobile threat telemetry, app inventory, privacy constraints, and whether devices are corporate-managed or user-owned.

Official MITRE ATT&CK definition

Screen Capture

Adversaries may use screen capture to collect additional information about a target device, such as applications running in the foreground, user data, credentials, or other sensitive information. Applications running in the background can capture screenshots or videos of another application running in the foreground by using the Android `MediaProjectionManager` (generally requires the device user to grant consent).[1][2] Background applications can also use Android accessibility services to capture screen contents being displayed by a foreground application.[3] An adversary with root access or Android Debug Bridge (adb) access could call the Android `screencap` or `screenrecord` commands.[4][5]

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

Associated objects

Groups, software, and campaigns

Malware Mobile

S0479: DEFENSOR ID

DEFENSOR ID is a banking trojan capable of clearing a victim’s bank account or cryptocurrency wallet and taking over email or social media accounts. DEFENSOR ID performs the majority of its malicious functionality by abusing Android’s accessibility service.[1]

Android
Tool Mobile

S0408: FlexiSpy

FlexiSpy is sophisticated surveillanceware for iOS and Android. Publicly-available, comprehensive analysis has only been found for the Android version.[1][2]

FlexiSpy markets itself as a parental control and employee monitoring application.[3]

Android
Malware Mobile

S1094: BRATA

BRATA (Brazilian Remote Access Tool, Android), is an evolving Android malware strain, detected in late 2018 and again in late 2021. Originating in Brazil, BRATA was later also found in the UK, Poland, Italy, Spain, and USA, where it is believed to have targeted financial institutions such as banks. There are currently three known variants of BRATA.[1][2][3]

Android
Malware Mobile

S1062: S.O.V.A.

S.O.V.A. is an Android banking trojan that was first identified in August 2021 and has subsequently been found in a variety of applications, including banking, cryptocurrency wallet/exchange, and shopping apps. S.O.V.A., which is Russian for "owl", contains features not commonly found in Android malware, such as session cookie theft.[1][2]

Android
Malware Mobile

S0407: Monokle

Monokle is targeted, sophisticated mobile surveillanceware. It is developed for Android, but there are some code artifacts that suggests an iOS version may be in development.[1]

Android
Malware Mobile

S0423: Ginp

Ginp is an Android banking trojan that has been used to target Spanish banks. Some of the code was taken directly from Anubis.[1]

Android
Malware Mobile

S0485: Mandrake

Mandrake is a sophisticated Android espionage platform that has been active in the wild since at least 2016. Mandrake is very actively maintained, with sophisticated features and attacks that are executed with surgical precision.

Mandrake has gone undetected for several years by providing legitimate, ad-free applications with social media and real reviews to back the apps. The malware is only activated when the operators issue a specific command.[1]

Android
Malware Mobile

S1069: TangleBot

TangleBot is SMS malware that was initially observed in September 2021, primarily targeting mobile users in the United States and Canada. TangleBot has used SMS text message lures about COVID-19 regulations and vaccines to trick mobile users into downloading the malware, similar to FluBot Android malware campaigns.[1]

Android
Malware Mobile

S1083: Chameleon

Chameleon is an Android banking trojan that can leverage Android’s Accessibility Services to perform malicious activities. Believed to have been first active in January 2023, Chameleon has been observed targeting users in Australia and Poland by masquerading as official applications. A new variant of Chameleon has expanded its targets to include Android users in the United Kingdom and Italy.[1][2]

Android
Relationship explorer

All related ATT&CK context

uses · Malware S0479: DEFENSOR ID Mobile uses · Tool S0408: FlexiSpy Mobile uses · Malware S1094: BRATA Mobile mitigates · Mitigation M1012: Enterprise Policy Mobile uses · Malware S1082: Sunbird Mobile uses · Malware S1062: S.O.V.A. Mobile mitigates · Mitigation M1011: User Guidance Mobile uses · Malware S0489: WolfRAT Mobile uses · Malware S0324: SpyDealer Mobile uses · Malware S0407: Monokle Mobile uses · Malware S0423: Ginp Mobile uses · Malware S0485: Mandrake Mobile uses · Malware S1069: TangleBot Mobile uses · Malware S1083: Chameleon Mobile uses · Malware S1054: Drinik Mobile uses · Malware S1079: BOULDSPY Mobile uses · Malware S0558: Tiktok Pro Mobile detects · Detection Strategy DET0668: Detection of Screen Capture Mobile uses · Malware S0422: Anubis Mobile uses · Malware S1077: Hornbill Mobile uses · Malware S0478: EventBot Mobile uses · Malware S1095: AhRat Mobile uses · Malware S0427: TrickMo Mobile uses · Malware S9004: Crocodilus Mobile
Mitigations

Mitigation direction

Mitigation Mobile

M1012: Enterprise Policy

An enterprise mobility management (EMM), also known as mobile device management (MDM), system can be used to provision policies to mobile devices to control aspects of their allowed behavior.

Mitigation Mobile

M1011: User Guidance

Describes any guidance or training given to users to set particular configuration settings or avoid specific potentially risky behaviors.

Mitigation Mobile

M1013: Application Developer Guidance

Application Developer Guidance focuses on providing developers with the knowledge, tools, and best practices needed to write secure code, reduce vulnerabilities, and implement secure design principles. By integrating security throughout the software development lifecycle (SDLC), this mitigation aims to prevent the introduction of exploitable weaknesses in applications, systems, and APIs. This mitigation can be implemented through the following measures: Preventing SQL Injection (Secure Coding Practice):

- Implementation: Train developers to use parameterized queries or prepared statements instead of directly embedding user input into SQL queries. - Use Case: A web application accepts user input to search a database. By sanitizing and validating user inputs, developers can prevent attackers from injecting malicious SQL commands.

Cross-Site Scripting (XSS) Mitigation:

- Implementation: Require developers to implement output encoding for all user-generated content displayed on a web page. - Use Case: An e-commerce site allows users to leave product reviews. Properly encoding and escaping user inputs prevents malicious scripts from being executed in other users’ browsers.

Secure API Design:

- Implementation: Train developers to authenticate all API endpoints and avoid exposing sensitive information in API responses. - Use Case: A mobile banking application uses APIs for account management. By enforcing token-based authentication for every API call, developers reduce the risk of unauthorized access.

Static Code Analysis in the Build Pipeline:

- Implementation: Incorporate tools into CI/CD pipelines to automatically scan for vulnerabilities during the build process. - Use Case: A fintech company integrates static analysis tools to detect hardcoded credentials in their source code before deployment.

Threat Modeling in the Design Phase:

- Implementation: Use frameworks like STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) to assess threats during application design. - Use Case: Before launching a customer portal, a SaaS company identifies potential abuse cases, such as session hijacking, and designs mitigations like secure session management.

**Tools for Implementation**:

- Static Code Analysis Tools: Use tools that can scan for known vulnerabilities in source code. - Dynamic Application Security Testing (DAST): Use tools like Burp Suite or OWASP ZAP to simulate runtime attacks and identify vulnerabilities. - Secure Frameworks: Recommend secure-by-default frameworks (e.g., Django for Python, Spring Security for Java) that enforce security best practices.

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .

ATT&CK release
19.1
Object version
1.3
Created
Modified
Raw hash
c6805ee8ecf31856...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.3 Current bundle c6805ee8ecf3…
Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Open mirrored raw JSON Open MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    Fortinet screencap July 2019

    Dario Durando. (2019, July 3). BianLian: A New Wave Emerges. Retrieved September 4, 2019.

    Open source URL
  2. [2]
    Android ScreenCap1 2019

    Android Developers. (n.d.). Android MediaProjectionManager. Retrieved August 8, 2019.

    Open source URL
  3. [3]
    Lookout-Monokle

    Bauer A., Kumar A., Hebeisen C., et al. (2019, July). Monokle: The Mobile Surveillance Tooling of the Special Technology Center. Retrieved September 4, 2019.

    Open source URL
  4. [4]
    Android ScreenCap2 2019

    Android Developers. (n.d.). Android Debug Bridge (adb). Retrieved August 8, 2019.

    Open source URL
  5. [5]
    Trend Micro ScreenCap July 2015

    Zhang, V. (2015, July 21). Hacking Team RCSAndroid Spying Tool Listens to Calls; Roots Devices to Get In. Retrieved August 8, 2019.

    Open source URL
  6. [6]
    NIST Mobile Threat Catalogue APP-40
    Open source URL
  7. [7]
    mitre-attack T1513
    Open source URL
Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use