M1011: User Guidance
Describes any guidance or training given to users to set particular configuration settings or avoid specific potentially risky behaviors.
Analyst context for executives and security teams
User Guidance is a mobile ATT&CK mitigation centered on teaching users which risky prompts, permissions, and behaviors to avoid or configure safely. Its business value is highest where mobile devices handle credentials, authentication codes, location data, calls, audio, notifications, or sensitive applications. The key decision is not whether training exists, but whether it is specific enough to reduce consent-based abuse such as approving third-party keyboards, accessibility access, microphone/location permissions, device administrator rights, SMS/call access, or suspicious mobile management requests.
Executive priority
Treat this as a resilience and risk-reduction control for mobile workforces, especially where mobile devices are used for identity verification, executive communications, field operations, or regulated data access. User guidance should be backed by measurable mobile governance evidence: what users are told, which device permissions are monitored, which risky grants are restricted, and how exceptions are reviewed. By itself, guidance is not a substitute for MDM/EMM controls, mobile telemetry, or incident response playbooks.
Technical view
ATT&CK provides no official detection text for M1011, so SOC and mobile security teams should validate this mitigation through the techniques it is mapped to. The relationship context points to Android and iOS risks involving input capture, keylogging, software/security software discovery, audio capture, location tracking, SIM swap, Android accessibility abuse, removable media/USB exposure, screen capture, notification access, SMS/call control, device administrator permissions, foreground persistence, execution guardrails/geofencing, hidden app icons, and defense impairment. Detection engineers should confirm whether mobile telemetry can show risky permission grants, changes to device administration or accessibility settings, third-party keyboard authorization, default SMS handler changes, location/microphone access, notification access, app inventory changes, and mobile management or cloud device-location console activity.
Likely telemetry
- MDM/EMM device inventory and compliance state
- Mobile application inventory and app install/uninstall records
- Android accessibility service enablement events
- Android device administrator permission grants and removals
- Mobile OS permission state for microphone, location, SMS, calls, notifications, screen capture, and related sensitive access
Detection direction
- Do not measure this mitigation only by completion of awareness training; validate whether device state and mobile telemetry show reduced risky permissions and configurations.
- Prioritize detection logic around user-consent events that enable sensitive access, including accessibility, device administrator, notification access, microphone, location, SMS, call, screen capture, and third-party keyboard permissions.
- Tune for context: some permissions are legitimate for approved business apps, accessibility tools, MDM agents, security products, and communications apps, so allowlisting and ownership metadata are important to reduce false positives.
- Look for combinations of risky grants rather than single events when possible, such as accessibility plus SMS access, device administrator plus uninstall resistance, or location access plus foreground persistence.
- Confirm whether Android-only relationships are covered separately from Android/iOS relationships; ATT&CK maps several related techniques to Android only.
Mitigation priorities
- Create mobile-specific user guidance that names the risky decisions users actually see: permission prompts, accessibility requests, third-party keyboard approvals, device administrator prompts, notification access, SMS/call access, location sharing, microphone access, and remote device-management requests.
- Pair guidance with enforceable mobile policy where possible, including MDM/EMM baselines, approved app sources, permission restrictions, app inventory review, and compliance reporting.
- Address identity and help desk processes tied to SIM swap risk, including user verification expectations and escalation paths for unexpected loss of service or account recovery prompts.
- Give users clear reporting channels for suspicious prompts, hidden or hard-to-remove apps, unexpected device management messages, unusual battery/sensor behavior, or changes to SMS/call behavior.
- For higher-risk users or regulated workflows, validate that guidance is evidenced through audits: training content, acknowledgement, device compliance snapshots, exception records, and incident response lessons learned.
Analyst notes and limits
This is a course-of-action object, not a technique. The official description is broad and the detection field is not provided, so the strongest analytic value comes from the listed mitigation relationships. The mapped techniques show that user guidance is most relevant when adversary behavior depends on user consent, permission grants, social engineering, or risky mobile configuration choices. Local mobile platform mix, MDM visibility, approved app catalog, and identity support processes will determine how actionable this mitigation is.
ATT&CK does not specify platforms or tactics for M1011 itself, and provides no official detection guidance. Platform references come from the related techniques only. This summary does not establish active exploitation, actor attribution, customer exposure, or guaranteed detection coverage. Organizations need local device telemetry and policy evidence to determine actual control effectiveness.
User Guidance
Describes any guidance or training given to users to set particular configuration settings or avoid specific potentially risky behaviors.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Mobile | T1541 | Foreground Persistence | If a user sees a persistent notification they do not recognize, they should uninstall the source application and look for other unwanted applications or anomalies. |
| Mobile | T1630.002 | File Deletion Sub-technique | Users should be trained on what device administrator permission request prompts look like, and how to avoid granting permissions on phishing popups. |
| Mobile | T1660 | Phishing | Users can be trained to identify social engineering techniques and phishing emails. |
| Mobile | T1632 | Subvert Trust Controls | Typically, insecure or malicious configuration settings are not installed without the user's consent. Users should be advised not to install unexpected configuration settings (CA certificates, iOS Configuration Profiles, Mobile Device Management server provisioning). |
| Mobile | T1516 | Input Injection | Users should be warned against granting access to accessibility features, and to carefully scrutinize applications that request this dangerous permission. |
| Mobile | T1418.001 | Security Software Discovery Sub-technique | iOS users should be instructed to not download applications from unofficial sources, as applications distributed via the Apple App Store cannot list installed applications on a device. |
| Mobile | T1643 | Generate Traffic from Victim | Users should be advised that applications generally do not require permission to send SMS messages. |
| Mobile | T1658 | Exploitation for Client Execution | Users should be wary of iMessages from unknown senders. Additionally, users should be instructed not to open unrecognized links or other attachments in text messages. |
| Mobile | T1517 | Access Notifications | Users should be wary of granting applications dangerous or privacy-intrusive permissions, such as access to notifications. |
| Mobile | T1430.001 | Remote Device Management Services Sub-technique | Users should protect their account credentials and enable multi-factor authentication options when available. |
| Mobile | T1644 | Out of Band Data | Users should be instructed to not grant applications unexpected or unnecessary permissions. |
| Mobile | T1513 | Screen Capture | Users should be advised not to grant consent for screen captures to occur unless expected. Users should avoid enabling USB debugging (Android Debug Bridge) unless explicitly required. |
| Mobile | T1629.003 | Disable or Modify Tools Sub-technique | Users should be taught the dangers of rooting or jailbreaking their device. |
| Mobile | T1453 | Abuse Accessibility Features | First, users should be wary of clicking on suspicious text messages, links and emails. Secondly, users should be wary of granting applications accessibility features. Users may check applications that have been granted accessibility features by going to Settings, then Accessibility. Finally, users should be wary of downloading applications; although applications may be on the Google Play Store, they may not be benign (see Application Versioning). |
| Mobile | T1417 | Input Capture | Users should be wary of granting applications dangerous or privacy-intrusive permissions, such as keyboard registration or accessibility service access. |
| Mobile | T1630.001 | Uninstall Malicious Application Sub-technique | Inform users that device rooting or granting unnecessary access to the accessibility service presents security risks that could be taken advantage of without their knowledge. |
| Mobile | T1521.003 | SSL Pinning Sub-technique | Users should be advised to not trust or install self-signed certificates. |
| Mobile | T1628.001 | Suppress Application Icon Sub-technique | Users should be shown what a synthetic activity looks like so they can scrutinize them in the future. |
| Mobile | T1635 | Steal Application Access Token | Users should be instructed to not open links in applications they don’t recognize. |
| Mobile | T1632.001 | Code Signing Policy Modification Sub-technique | Typically, insecure or malicious configuration settings are not installed without the user's consent. Users should be advised not to install unexpected configuration settings (CA certificates, iOS Configuration Profiles, Mobile Device Management server provisioning). |
| Mobile | T1640 | Account Access Removal | Users should be taught that Device Administrator permissions are very dangerous, and very few applications need it. |
| Mobile | T1627.001 | Geofencing Sub-technique | Users should be advised to be extra scrutinous of applications that request location, and to deny any permissions requests for applications they do not recognize. |
| Mobile | T1418 | Software Discovery | iOS users should be instructed to not download applications from unofficial sources, as applications distributed via the Apple App Store cannot list installed applications on a device. |
| Mobile | T1676 | Linked Devices | For Android devices, users should be advised to enable Google Play Protect, which checks the device itself and the applications for malicious behavior. For iOS devices, users who are concerned about being targeted should consider enabling Lockdown Mode, which provides extreme protection of the device as well as data stored and transmitted. In general, users should be advised against scanning QR codes and/or clicking on suspicious links or text messages, which may masquerade as device-linking instructions by Signal or WhatsApp. |
| Mobile | T1636.002 | Call Log Sub-technique | Call Log access an uncommonly needed permission, so users should be instructedto use extra scrutiny when granting access to their call logs. |
| Mobile | T1430 | Location Tracking | Users should be wary of granting applications dangerous or privacy-intrusive permissions, such as access to location information. Users should also protect their account credentials and enable multi-factor authentication options when available. |
| Mobile | T1635.001 | URI Hijacking Sub-technique | Users should be instructed to not open links in applications they don’t recognize. |
| Mobile | T1662 | Data Destruction | Users should be trained on what device administrator permission request prompts look like, and how to avoid granting permissions on phishing popups. |
| Mobile | T1642 | Endpoint Denial of Service | Users should be cautioned against granting administrative access to applications. |
| Mobile | T1582 | SMS Control | Users should be encouraged to be very careful with what applications they grant SMS access to. Further, users should not change their default SMS handler to applications they do not recognize.CitationSMS KitKat |
| Mobile | T1629 | Impair Defenses | Providing user guidance around commonly abused features, such as the modal that requests for administrator permissions, should aid in preventing impairing defenses. |
| Mobile | T1417.001 | Keylogging Sub-technique | Users should be wary of granting applications dangerous or privacy-intrusive permissions, such as keyboard registration or accessibility service access. |
| Mobile | T1616 | Call Control | Users should be encouraged to be very careful with what applications they grant phone call-based permissions to. Further, users should not change their default call handler to applications they do not recognize. |
| Mobile | T1627 | Execution Guardrails | Users should be advised to be extra scrutinous of applications that request location or sensitive phone information permissions, and to deny any permissions requests for applications they do not recognize. |
| Mobile | T1451 | SIM Card Swap | The user should become familiar with social engineering tactics that ask for Personally Identifiable Information (PII). Additionally, the user should include the use of hardware tokens, biometrics, and other non-SMS based authentication mechanisms where possible. Finally, the user should enable SIM swapping protections offered by the mobile carrier, such as setting up a PIN or password to authorize any changes to the account. |
| Mobile | T1626.001 | Device Administrator Permissions Sub-technique | Users should scrutinize every device administration permission request. If the request is not expected or the user does not recognize the application, the application should be uninstalled immediately. |
| Mobile | T1629.001 | Prevent Application Removal Sub-technique | Users should be warned against granting access to accessibility features and device administration services, and to carefully scrutinize applications that request these dangerous permissions. Users should be taught how to boot into safe mode to uninstall malicious applications that may be interfering with the uninstallation process. |
| Mobile | T1655.001 | Match Legitimate Name or Location Sub-technique | Users should be encouraged to only install apps from authorized app stores, which are less likely to contain malicious repackaged apps. |
| Mobile | T1458 | Replication Through Removable Media | Users should be advised not to use public charging stations or computers to charge their devices. Instead, users should be issued a charger acquired from a trustworthy source. Users should be advised not to click on device prompts to trust attached computers unless absolutely necessary. |
| Mobile | T1636 | Protected User Data | Users should be taught the danger behind granting unnecessary permissions to an application and should be advised to use extra scrutiny when an application requests them. |
| Mobile | T1655 | Masquerading | Users should be encouraged to only install apps from authorized app stores, which are less likely to contain malicious repackaged apps. |
| Mobile | T1636.004 | SMS Messages Sub-technique | Access to SMS messages is an uncommonly needed permission, so users should be instructed to use extra scrutiny when granting access to their SMS messages. |
| Mobile | T1636.001 | Calendar Entries Sub-technique | Calendar access is an uncommonly needed permission, so users should be instructed to use extra scrutiny when granting access to their device calendar. |
| Mobile | T1630 | Indicator Removal on Host | Inform users that device rooting or granting unnecessary access to the accessibility service presents security risks that could be taken advantage of without their knowledge. |
| Mobile | T1670 | Virtualization Solution | Users should be encouraged to only install apps from authorized app stores, which are less likely to contain malicious applications. |
| Mobile | T1663 | Remote Access Software | Users should be encouraged to be very careful with granting dangerous permissions, such as device administrator or access to device accessibility. |
| Mobile | T1636.003 | Contact List Sub-technique | Contact list access is an uncommonly needed permission, so users should be instructed to use extra scrutiny when granting access to their contact list. |
| Mobile | T1429 | Audio Capture | Users should be wary of granting applications dangerous or privacy-intrusive permissions, such as access to microphone or audio output. |
| Mobile | T1636.005 | Accounts Sub-technique | Access to accounts is an uncommonly needed permission, so users should be instructed to use extra scrutiny when granting access to their accounts. |
All related ATT&CK context
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 .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 78639487f8cd… |
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.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack M1011Open source URL
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.