How BAD is MAM?

Everyone who says that MAM is a security solution is wrong. MAM is bad at security. It is a common perception that MAM can solve your mobile endpoint security issues. That is flawed at the core. MAM is short for Mobile Application Management. By its own definition, it is a management tool specific to managing applications. That is not security – it is a configuration and policy enforcement library for SOME of the applications on a mobile device.

Somehow, MDM vendors have convinced administrators and security professionals that a tool that only manages applications and not the device (what MDM is supposedly good at) is an acceptable way to protect your corporate data on an unmanaged, BYOD device.

The logic flaw in mobile device security is that any organization could guarantee their proprietary information was secure using ANY Mobile Application Management (MAM) solution. It was not designed to protect your data, it was designed to manage your application and enable some application protection features.

What is MAM? How does it work?

MAM is fundamentally a policy enforcement tool not a mobile device or application hardener. As a policy enforcement tool, it tries to secure data by enforcing policies on applications. Its security controls can enforce behaviors within governed apps like downloading, copying/pasting, using screen PINs, or conditional access based on location (if enabled) or root detection.

What is MAM supposed to be used for? In a BYOD setting where companies want to give access to corporate resources without the administrative headache or cost of providing phones, MAM is an alternative to the privacy incursions of MDM with full device security controls. The “marketing” idea with MAM is that it can secure the applications and data on the device using policy enforcement. A MAM implementation must trust the device operating system in order to securely provide its configuration and policy functions.

How Does MAM manage Applications?

Because MAM is just a collection of applications and libraries – it is not part of the operating system or the trusted computing base - it relies on applications to participate in their management. Few applications come out of the app stores ready to be managed by a MAM solution. If the applications an administrator wants to provide are not configured to work with the MAM solution of choice, they have few options. They can try to convince the vendor of the application to embed the MAM vendor’s API calls into their application OR the administrator could “wrap” the application themselves and repackage and install it on the mobile devices. Following that path results in a special version of the application that the vendor will not warrant nor support. The result is a lot fewer applications to choose from.

MAM Security – a House of Cards!

Most MAM implementations come with some form of jailbreak/root detection. This is their lynchpin — if the device is rooted or jailbroken, the entire MAM security model assumes it can detect that state and cut off access. But that dependency exposes the flaw: root detection is not zero trust. Zero trust means you never rely on the integrity of the endpoint, yet MAM literally builds its foundation on trusting the device to tell the truth about itself.

If a zero-day exploit does not alter the behaviors or files that the MAM looks for, then escalated privileges can be gained by an adversary and the security capabilities nullified. Advanced jailbreak and rooting tools are designed to evade detection from MAM and MDM solutions. Android toolsets designed to prevent detection like MagiskHide, Zygisk, or Shamiko continue to evolve to hide a device compromised state from security checks.

Common specific iOS jailbreak detection bypass tools include Liberty Lite, Shadow, A-Bypass, FlyJB X, and iHide. These known tools work to hide specific files, directories, and other system modifications that apps look for to determine if a device is jailbroken. These attackers regularly use frameworks like Frida to "hook" or intercept specific function calls within an application that are used for jailbreak detection.

For more complex detection methods, attackers may reverse-engineer the application's binary code and manually patch or remove the jailbreak detection logic before repacking and reinstalling the app. The attacker can then alter the return value of the function to lie to the app, making it believe the device is not compromised. MAM capabilities do not use code obfuscation techniques to mitigate reverse engineering or these techniques.

These are known capabilities with a likeliness that root/jailbreak detection capabilities are aware of and try to detect these threats. Once discovered, MAM vendors work to mitigate the risk and improve detection, and then the update must be applied and that can be a configuration management nightmare! This continues to be a cat and mouse game that requires a dedicated capability to counter.

With root access, an attacker can disable or alter core OS security features like Secure Boot or Data Execution Prevention. Attackers can use their elevated privileges to install persistent malware or rootkits that are difficult or impossible for the average user to detect and remove. The goal of any advanced persistent threat is to gain and maintain access to any compromised device. As soon as possible, the threat will remove any indicator of compromise from a rooted/jailbroken device to make the device look normal including changing hash values to evade signature-based antivirus detection. The result is that MAM deployed with Endpoint Detection and Response (EDR) will fail to detect, report, or mitigate any threats.

IF a MAM solution can detect rooted / jailbroken devices, it can block access to corporate resources. In theory, the protected and encrypted container protects the data, but as stated above MAM does not harden apps, it controls app policy and can encrypt files within the application file store. MAM may invoke the FIPS 140-3 validated encryption protected with the Android or iOS device keystore/vault to protect the data. However, the MAM and protected app must use the authentication service on a device such as a PIN or biometrics to gain access to the app and file store. Since the data is stored on the device, a threat actor can use specific capabilities to get to the data. For example, they could use memory scraping. They could install a high-privileged process to read decrypted data from an application's memory while the application is running. Protected apps must decrypt their data into memory to allow the user to work with it, creating a brief window of vulnerability.

A threat with privileged access could install a rogue application that uses their corporate identity to request a token from an identity provider to authenticate access to read and export the corporate data. If the MAM “health check” fails to detect the compromised status on the device, then the threat actor may be able to establish privileged access to manipulate the OS and bypass MAM protections. Additionally privileged access on a device could capture decrypted data by logging keystrokes, taking screenshots of sensitive information as it is being viewed, or recording the screen.

MAM normally uses “Select Wipe” to remove just the application data but in regulated industries such as the DoD, this does not meet the requirements for removing the data from the device. Factory reset would be the bare minimum requirement to ensure the certs and data are removed which can impact the user greatly. Even in less regulated industries, some applications do not segregate their data. If such an application is being used by the consumer AND by the corporation, wiping the application’s data can result in the loss of the user’s personal data.

If MAM encryption is used to protect the data, how would a threat actor defeat this? If your phone is infected and IoC is not detected, malware could intercept authentication codes and bypass the MAM security. Threat actors could also send Smishing links or notifications to trick an end user into approving a malicious login. If the encryption keys are protected using biometrics, any biometric requests would be presented by the application. Only the most security aware users will suspect that the biometric request was legitimate, or the result of malware attached to the application.

Additionally, many financial apps and MAM solutions rely on SSL pinning to prevent man-in-the-middle attacks. However, tweaks like "SSL Kill Switch" can disable this security measure, allowing attackers to intercept and analyze encrypted network traffic.

Additionally, because MAM/EDR do not control network traffic, and normally communicate over port 443, they cannot stop the Command-and-Control channels that are established for the device access and data exfiltration.

"The only way to make a man trustworthy is to trust him” (Henry Stimson, or was it an unknown MAM creator??)

Why MAM Cannot Deliver Zero Trust

How to mitigate risk for MAM is to get closer to trusting the device or at least the device OS. The IT staff has to ensure that the MAM and any supporting EDR is configured and managed to protect data and access while protecting personal privacy. They have to ensure that access is conditional on the security status of the device policies to ensure that only "healthy" and compliant devices can access corporate data. They have to ensure that the end user continuously updates the device OS, MAM and EDR apps. And they have to educate their users on the importance of security on their devices. This constant burden on the users will affect user adoption.

According to a recent Zimperium¹ report, 50% of all mobile device OS’s are outdated and 25% cannot be updated. And yet we are relying on updated devices to keep ahead of the “cat and mouse game.” Sophisticated tools such as Pegasus present a very dangerous threat using a “zero-click” or “missed called” exploit². Once again there is no guarantee of security when the data, the application and the security all comingle on an unmanaged device that is continuous exposed to a variety of wireless networks and services.

In fairness to MAM, it was never designed to be a zero-trust security solution. It can’t be because it has to trust the device at some level without violating privacy. Especially in a BYOD scenario where the end user device just expands a corporate attack surface to an unsecure and unmanaged device. As depicted above, there are too many malicious tools and too many variables to lend any prudent security professional to believe they can mitigate risk to an acceptable level in order to maintain a BYOD program.

Zero Trust BYOD

While zero trust BYOD is elusive, there is hope. Hypori Mobile uses a secure Virtual Mobile Infrastructure (VMI) environment to remove the end user device from the attack surface of any enterprise environment. It has been built to mitigate or eliminate every possible attack vector outlined in the paper because data is never transmitted to, stored on or processed within the end user device. Instead, the end user interacts with a window into their Virtual Workspace that is all provided within a fully monitored and controlled secure cloud environment.

The only element stored on the device is the end user’s certificate. To prevent key extraction, Hypori Mobile keys are stored inside the secure hardware and can only be used for cryptographic operations within that environment. The key material is never exposed to the device OS, making it non-exportable. The system binds keys to the secure hardware of the device (TEE or SE). This means that even if a device is rooted, an attacker cannot extract the private keys. Key use is strictly controlled through the use of biometrics enforced by the hardware.

The Hypori Mobile app also uses advanced obfuscation and detection capabilities to protect the app from reverse engineering / compromised access. If a compromise is detected, the device will not connect to the Hypori Mobile backend. And the authentication into the Hypori Virtual Workspace is separate and distinct from the customer access control into their enterprise services, data or resources. If a threat actor was able to get into the Hypori Virtual Workspace from a compromised device, they would also have to be able to compromise the Virtual Workspace without going through the end user device since there is no way to upload code via that path. This significantly reduces risk to gain access to enterprise services, data or resources from the device.

Learn more about Hypori

‍

‍

‍

References:

¹ https://lp.zimperium.com/hubfs/Reports/2025%20Global%20Mobile%20Threat%20Report.pdf

² https://ijcrd.com/files/Vol_11_issue_4/1142.pdf

‍