Mobile T1632 Subvert Trust Controls: Exposing Mobile Evasion With MDM, MTD and Forensics

Mobile operating systems decide what may run, what may be trusted and what the user is warned about, and attackers who talk a user or a script into changing those decisions get malware onto a phone without breaking any code signature. MITRE ATT&CK for Mobile tracks this as T1632 Subvert Trust Controls, a Defense Evasion technique listed for both Android and iOS, with one sub-technique, T1632.001 Code Signing Policy Modification. This guide covers how the technique shows up on each platform, the device management settings that close it, what to look for in MDM, mobile threat defence (MTD) and forensic data, and how to respond. It is written for endpoint, mobility and SOC teams. For the matrix as a whole, see the MITRE ATT&CK for Mobile Guide.

Key takeaways

• The trust decision is the target. T1632 abuses the user's ability to allow unknown sources, trust an enterprise developer, install a configuration profile or trust a root certificate, so policy that removes those choices is the main control.
• Both platforms are in scope. ATT&CK lists Android and iOS: on Android the usual path is "install unknown apps"; on iOS it is enterprise-signed apps, malicious configuration profiles and rogue MDM enrolment.
• Managed devices can lock the door. ATT&CK names the iOS restrictions allowEnterpriseAppTrust and allowEnterpriseAppTrustModification; Android Enterprise can block unknown-source installs through user restrictions.
• Detection is mostly state, not events. Watch profile lists, installed app inventories, installer source and signing certificates from MDM, and alert on drift from the approved baseline.
• Certificates and profiles are identities too. A trusted root or enterprise signing certificate is a machine credential that the device obeys, so inventory and allow-list them like any other non-human identity.

What T1632 covers

ATT&CK describes Subvert Trust Controls as undermining security controls that either warn users about untrusted activity or prevent untrusted applications from running. Its examples are an app allowed to run because it carries a valid signature, an OS prompt that an app came from an untrusted source, and a warning before connecting to an untrusted site. The method depends on the mechanism being subverted.

The sub-technique T1632.001 Code Signing Policy Modification covers changing code signing policy so apps signed with unofficial or unknown keys can run. ATT&CK notes that mobile devices enable these controls by default, for example by blocking unknown app installs on Android, and that adversaries change them through Input Injection (T1516) or malicious configuration profiles. T1632.001 replaced the older ID T1478 Install Insecure or Malicious Configuration, which ATT&CK now shows as revoked. The Enterprise equivalent is T1553, covered in the MITRE ATT&CK T1553 Subvert Trust Controls guide.

How it shows up on Android and iOS

Procedure examples from ATT&CK

• Android unknown sources: ATT&CK records Dvmap (S0420) and Mandrake (S0485) enabling installation from unknown sources, and SilkBean (S0549) trying to trick users into enabling it.
• iOS enterprise signing: YiSpecter (S0311) signed malicious apps with iOS enterprise certificates so they ran on non-jailbroken devices, according to ATT&CK.
• iOS profiles and MDM: XLoader for iOS (S0490) was installed through a malicious configuration profile; TianySpy (S1056) installed malicious configurations to allow Ad Hoc distribution; Windshift (G0112) installed malicious MDM profiles on iOS devices during Operation ROCK.

Prevention: settings that remove the trust decision

ATT&CK lists three mitigations: M1012 Enterprise Policy, M1006 Use Recent OS Version and M1011 User Guidance. The table maps them to concrete controls.

Apple's guidance is that certificates deployed through MDM or Apple Configurator are trusted automatically, and enterprise apps deployed through MDM are trusted without the user approving the developer. That is the reason to route every certificate and in-house app through management: once nothing legitimate needs a manual trust step, any manual trust step is suspicious. See the iOS and iPadOS Enterprise Security Guide and the Android Enterprise Security Guide.

Detection with MDM, MTD and forensics

ATT&CK's detection strategy for T1632 relies on management state and application vetting rather than live device events. On iOS it treats MDM queries as periodic observations. That shapes what a SOC can realistically alert on.

• iOS MDM state: poll ProfileList, SecurityInfo and InstalledApplicationList; alert on any profile not issued by your MDM, any app signed by an enterprise certificate not on your allow-list, and any change to restrictions.
• Android management state: report the installer package for each app, alert when an app arrives from a source outside managed Google Play, and alert when "install unknown apps" is granted to any package on a device that should not allow it.
• App and device verdicts: Play Integrity appRecognitionVerdict returns UNRECOGNIZED_VERSION when an app's certificate or package name does not match Play records, and the opt-in playProtectVerdict reports POSSIBLE_RISK when Play Protect is off. Feed these into conditional access.
• MTD: mobile threat defence agents flag sideloaded apps, unknown profiles and user-installed CAs; forward their alerts to the SIEM with device and user identifiers.
• Forensics: the Mobile Verification Toolkit (MVT), from Amnesty International's Security Lab, supports consensual analysis of iOS backups, filesystem dumps and sysdiagnose files and Android backups against published indicators.

Metrics that show it is working

• Percentage of managed devices with unknown-source installs blocked (Android) and enterprise app trust disabled (iOS).
• Count of devices with a configuration profile or root certificate not issued by your MDM (target: zero).
• Count of installed apps signed by certificates outside the allow-list.
• Mean time from MDM drift alert to quarantine.
• Share of devices reporting a healthy Play Integrity or attestation verdict at access time.

Response

1. Contain: mark the device non-compliant so conditional access blocks corporate apps and tokens.
2. Preserve: export the MDM profile list, app inventory and MTD alert, and take a backup or sysdiagnose for MVT before removal if the user consents.
3. Remove: delete the rogue profile, untrust the enterprise developer (on iOS, deleting all apps from that developer revokes trust), remove the sideloaded app and revoke the "install unknown apps" grant.
4. Rotate: revoke OAuth refresh tokens and app sessions issued to that device, since a rogue profile or CA may have exposed traffic.
5. Escalate for high-risk users: follow the Mobile Spyware Infection Response Playbook.

Where identity fits

Every trust control in T1632 is anchored on a credential that is not a person: a code signing certificate, an enterprise distribution certificate, a CA in the trust store, or the MDM server's identity in an enrolment profile. Treat them as non-human identities with an owner, an inventory and an expiry. Keep enterprise distribution keys in managed signing services, as described in the Code Signing Security Guide, and protect MDM administrator and API credentials as described in the Mobile Device Management Security Guide.

Common failure patterns

• Distributing in-house apps by link: teaching users to trust an enterprise developer manually trains them to do the same for an attacker.
• Proxy CAs pushed as user certificates: asking staff to install an inspection root by hand normalises the exact action T1632 relies on.
• BYOD with no restrictions: user enrolment and personal devices get fewer controls, so unknown sources and manual profiles remain open; set access policy accordingly.
• Restrictions without monitoring: settings are applied once and never re-checked, so a removed profile or changed restriction is not noticed.
• Ignoring accessibility abuse: on Android, Input Injection can grant the unknown-sources permission without the user meaning to; restrict accessibility services on managed devices.

Framework mapping

Practitioner checklist

• Block unknown-source installs on all managed Android devices and work profiles.
• Set allowEnterpriseAppTrust and allowEnterpriseAppTrustModification to false on managed iOS devices and deliver in-house apps through MDM.
• Deploy every required root certificate through MDM and stop all manual certificate installs.
• Keep an allow-list of signing certificates and profile issuers, and alert on anything outside it.
• Gate corporate access on Play Integrity or managed device attestation and current OS versions.
• Enable Lockdown Mode or Android Advanced Protection for high-risk users.
• Rehearse the response: isolate, preserve MVT inputs, remove, rotate tokens.
• Brief users that no legitimate request will ask them to install a profile or trust a developer by hand.

Standards and references

• MITRE ATT&CK: T1632 Subvert Trust Controls (Mobile)
• MITRE ATT&CK: T1632.001 Code Signing Policy Modification
• Apple Support: Install custom enterprise apps on iOS, iPadOS and visionOS
• Apple Support: Trust manually installed certificate profiles in iOS and iPadOS
• Apple Support: About Lockdown Mode
• Android Developers: Network security configuration
• Android Developers: Play Integrity API integrity verdicts
• Amnesty International Security Lab: Mobile Verification Toolkit documentation

Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · Mobile Device Management Security Guide · Mobile Threat Defense Buyer's Guide · Apple Lockdown Mode Guide