Android and malware

Jonas Bøgvad
Jonas Bøgvad

Table of Contents

So, I just read an article that said researchers had found dozens of malware-infected Android apps that had been downloaded more than 10 million times from the Google Play store.

"Upon launching, they asked potential victims to log in to their accounts and then loaded a genuine Facebook authorization page," Dr.Web researchers said. "Next, they hijacked the authentication data and sent it to malicious actors."

Let that sick in... 10 million downloads.

App protection policies enough?

Let me be honest: I do like using App Protection Policies (from now on, APP), which are part of our EMS E3 license because we satisfy privacy "feelings". But is it enough? Are we safe enough if we only use APP that keep our business data and personal data separate. APP protect an organization's data in a managed app. A policy can be a rule enforced when a user tries to access or move "corporate" data or a set of prohibited or monitored app actions. Intune can manage managed apps with APP.

APP can be used in either scenario, whether or not the device has been enrolled. What they both have in common is that we force our users to use Microsoft Apps with Office 365.

Personal owned called Bring Your Own Device(BYOD):

  • Unmanaged BYOD with APP (not enrolled)
  • Android Enterprise(personal owned with work profile) with APP (enrolled)

But why aren't we enrolling our devices either way? Usually, our users and people higher up in the command chain are against it, because if we force our users to enrol, we're taking ownership of their device. Some people would say yes and others would say no, but overall, users feel like we are taking control of their devices and making them feel less private.

One thing to keep in mind is that if you allow personal devices to access your environment via APP without enrollment or with enrollment, we also allow Android applications with possible Malware. We have no control over which applications we can or cannot install that is all up to the user.

App Protection Policies require company portal or authenticator app installed.

Following screenshot will prove my point in Intune that we can only take control over applications from Google Play store if;

Corporate owned:

  • Fully Managed, dedicated
  • Corporate-owned work profile devices

Microsoft Defender for Endpoint (MDE) - Mobile Threat Defense (MTD)

My scenario from the above section in a Personal owned scenario makes me fell that we need something more, if we are letting personal devices access our Office 365 data (Sharepoint Online, Exchange Online). Although security frameworks recommend that we enrol personal(BYOD) devices, we will still be unable to control which applications can be installed. If we have made the security assessment and allowed personal owned devices.

But I strongly recommend that you also think about exposure, every possible application rises our devices exposure to a potential risk.

NIST and CIS security standards require full control, which we won't have on a personal device.

Unmanaged BYOD with APP (BYOD)

Unmanaged BYOD with APP we are able to get risk signals with Microsoft Defender for Android, which will be forced to be installed if required in our APP conditional launch policies.

Unfortunate we are only given limited risk signals because of privacy and lack of management possibilities except in managed apps.

Managed with APP (BYOD)

Managed with APP we are able to get risk signals with Microsoft Defender for Android, which will be forced to be installed either by Intune or APP conditional launch policies.

Because the device is managed, we can receive even more risk signals and configure our devices to a minimum security level.

Conditional launch in App Protection Policies

Lets dig into each setting:

Max allowed device threat level requires (Microsoft Defender for Endpoint)

Rooted devices

Rooting is the process of giving users of the Android mobile operating system "root access," which gives them control over different parts of Android. Since Android is based on a modified version of the Linux kernel, rooting an Android device gives the same access to administrative (superuser) permissions as Linux or any other Unix-like operating system like FreeBSD or macOS.

Superuser on Linux = Local administrator on Windows

Max allowed device threat level

The device threat level is decided by Microsoft Defender for Endpoint - Mobile Threat Defense (MTD) with Threat Vulnerability Management. Each risk signal count raises the score, which shows up in the TVM portal so you can fix it with Endpoint Manager Intune device configurations(DC).

App protection policies uses Intune-MTD. Microsoft Defender for Endpoint app determines threats. Choose secure, low, medium, or high. Secured requires no threats on the device and is the most stringent.

SafetyNet device attestation

SafetyNet Attestation API is an anti-abuse API that lets app developers check the Android device their app is running on. The API should be used as part of your abuse detection system to determine if your servers are interacting with a genuine Android app and device.

SafetyNet Attestation API provides a cryptographically-signed attestation of the device's integrity. In order to create the attestation, the API examines the device's software and hardware for integrity issues and compares it to reference data for approved Android devices. Generated attestation is bound to caller app nonce. The attestation has a timestamp and metadata about the requesting app.

Require device lock

In a Unmanaged BYOD with APP (BYOD) scenario we are actually able to require a device lock before gaining access to the Android device without being managed.

Min Company portal version

Unmanaged BYOD with APP (BYOD), we can't deploy any apps, so we won't be able to force the latest updates unless the device does it automatically or the user does it themselves. It's a good idea to keep the build version close to the latest (keep this one updated)

Require threat scan apps

Some of Google Play Protect's APIs can be used with app protection policies. This setting makes sure that Google's Verify Apps scan is on for devices used by end users. If set up, the end user won't be able to get in until they turn on Google's app scanning on their Android device.

Want to experience Microsoft Defender for Endpoint? Sign up for a free trial.

Conclusion

We can get a long way with conditional launch by using APP, but we should always at least use Microsoft's MDT with MDE to make sure we are aware of threat vulnerability management.

We have to use company-owned devices if we want to meet security standards like CIS or NIST. Since this lets us see what apps we've installed on each device and gives us the option to get rid of apps we don't need by blacklisting or whitelisting them.

Sources

Rooting (Android) - Wikipedia
SafetyNet Attestation API | Android Developers
The SafetyNet Attestation API provides services for determining whether a device running your app satisfies Android compatibility tests.
These 28+ Android Apps with 10 Million Downloads from the Play Store Contain Malware
Researchers have discovered dozens of malware-infected Android apps that have been downloaded more than 10 million times from the Google Play Store.
Android app protection policy settings - Microsoft Intune
This topic describes the app protection policy settings for Android devices.