Hijacking 2FA – A look at Mobile Malware Through an Identity Lens

Introduction

In the last weeks, several news outlets reported on a new Android malware variant, that added capabilities to steal second-factor authentication codes using innovative ways. The original report from Threat Fabric includes interesting details about the overall malware behavior. In this post we’re going to focus on these new capabilities, review them from an identity perspective, and discuss what does it mean for identity security in general and for authentication strategies in particular.

Multi-factor Authentication and Mobile Apps

Mobile devices are a central piece of any modern authentication strategy. Whether part of password-less login flows as a Push-to-Accept factor, used as strong security keys in FIDO2-enabled login experiences, to generate one-time passwords (OTP) or employed to obtain sometimes not-so-secure but ubiquitous SMS-based access codes, mobile devices appear in almost every access scheme.

Mobile applications have their part, by acting as a mechanism to bring and deliver those access methods to the user. Most of the IAM vendors have their own mobile applications, that enable the implementation of different use cases, ranging from pretty basic second factor (2FA) and TOTP methods to more advanced use cases such as FIDO2 compatible security keys and authentication factors like SecureAuth’s Symbol to Accept.

Multi-Factor Authentication (MFA) mobile applications plays then a crucial role on securing access to employee and consumer applications, and to some degree are turned into trust anchors for the organization deploying them. Weaknesses or deficiencies on MFA mobile applications can then result in a degraded security posture, as threat actors might abuse them in order to circumvent the access mechanisms imposed.

How Malware Steals 2FA Codes or Bypass MFA

Every year, more companies are falling victim to mobile security issues. Verizon’s Mobile Security Index report for 2020 shows that 39% of organizations have experienced security compromises involving mobile devices, up from 33% in the 2019 report.

The most prevalent entry point for mobile malware is phishing, where users are enticed to install a malicious application. According to Wandera’s Mobile Phishing Report, the more common phishing delivery type is messaging, followed by social media and email.

An interesting point is that once a malicious application is installed on the victim’s device, it doesn’t necessarily need to leverage an operating system or device vulnerability. While some malware families rely on exploiting vulnerabilities to drop the malicious code or gain higher privileges, the more common practice instead is to request special permissions and then abuse the operating system’s features for carrying on the activity.

With regards to authentication, mobile malware targeting 2FA or MFA methods is not something new and has been around for quite some time. Traditionally, the more common technique of stealing 2FA codes is the capture of SMS messages. For example, before Android restricted the use of SMS and Call Log permissions in Android apps in March 2019, malware applications were abusing those rights to get access to OTPs delivered via messaging or voice. These techniques are still around as the mobile device install base is still moving to upgrade to newer Android versions that will prevent it.

Most of these malicious applications target financial applications, where the obtained credentials and codes can be easily monetized, such as the case of Gustuff or Monokle. As an example, ESET reported last year about an Android malware variant that was abusing permissions, such as access notifications, to gain access to one-time-passwords delivered via SMS before the user noticed them, bypassing this new Android protection mechanism.

Other malware makes use of different techniques to gain access to the victim’s resources, even if the target applications have 2FA protections in place. An example is a banking trojan also reported by ESET, which abuses Android’s Accessibility Services to interact with Paypal’s mobile application and mimic a user’s input in order to perform fraudulent transactions on its behalf. Even if the victim has an MFA method enabled, the malicious application can interact with the application, bypassing this protection.

The Cerberus Malware Case Study

In February 2020, Threat Fabric reported on a new variant of the Cerberus malware. This malware has been operating and very active at least since June 2019. The initial versions of Cerberus included features such as the ability to take screenshots, track device location, send and receive SMS messages and a screen lock credential (PIN) stealing function by performing an “overlay attack”.

According to the researchers, the new variants found showed a refreshed code base that included advanced capabilities that position the malware on the category of a Remote Access Trojan (RAT). The new ability that caught our attention was the 2FA stealing, so we decided to take a deeper look. The process involved both static and dynamic analysis of the samples, as it uses techniques such as dynamically loading code using reflection and encryption and encoding of classes and strings.

Similar to other malware families and as already mentioned, Cerberus declares an Accessibility Service and abuses the APIs offered by the operating system to perform several actions.

<?xml version="1.0" encoding="utf-8" standalone="no"?><manifest xmlns:android="http://schemas.android.com/apk/res/android" android:compileSdkVersion="23" android:compileSdkVersionCodename="6.0-2438415" package="scissors.boss.wide" platformBuildVersionCode="23" platformBuildVersionName="6.0-2438415"> <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/> <uses-permission android:name="android.permission.READ_PHONE_STATE"/> <uses-permission android:name="android.permission.INTERNET"/> <uses-permission android:name="android.permission.SEND_SMS"/> <uses-permission android:name="android.permission.SET_WALLPAPER_HINTS"/> <uses-permission android:name="android.permission.GET_ACCOUNTS"/> <uses-permission android:name="android.permission.READ_SMS"/> <uses-permission android:name="android.permission.CALL_PHONE"/> [..] <application android:allowBackup="true" android:icon="@mipmap/ic_launcher" android:label="Android System Update " android:name="scissors.boss.wide.KHzDgUaBcEzGqKlOyXtYxQkFwYkQbWkNdAyZe" android:roundIcon="@mipmap/ic_launcher_round" android:supportsRtl="true" android:theme="@android:style/Theme.Translucent.NoTitleBar"> <activity android:label="label_cigar" android:name="glare.bridge.rigid.WOiOfMbUlJgRfEpWlWkDaUgLeUtCmFhWeXaUf"/> [..] <activity android:name="glare.bridge.rigid.FKoCzCdSyBiIaJdDoCtFqWhWuQsKxJmXfRrHuFwKkJjCdGwBaLg" android:screenOrientation="portrait"/> <service android:label="Aggiornamento del sistema" android:name="glare.bridge.rigid.uyzdrrhtqm" android:permission="android.permission.BIND_ACCESSIBILITY_SERVICE"> <intent-filter> <action android:name="android.accessibilityservice.AccessibilityService"/> </intent-filter> <meta-data android:name="android.accessibilityservice" android:resource="@xml/qnvmgc"/> </service> <activity android:label="label_plug" android:name="glare.bridge.rigid.XQxBpYfXuOtAuGfAyYeXnBjYqHoLpYpOtLwWdAyZgPa"/> <activity android:name="glare.bridge.rigid.PTdLwOeMnSaIdNwHpBtSaUzNjFnYdZqWoEhCmEgOcPrNuAgGgJwDr" android:screenOrientation="landscape"/> </application> </manifest>

Excerpt of the “AndroidManifest.xml” file for one of the samples

Upon installation and initial launch, it asks the victim to enable the application as this type of service. The malicious application continues to prompt the victim until the user finally grants permissions.

Screenshot of the malicious app requesting Accessibility permissions

The accessibility features are then used to interact with the device and its applications, and perform a large set of evasion actions, such as avoid the uninstallation of the application, disable Google Play Protect or avoid the removal of assigned permissions. In addition, it listens in the background for all interactions and applications launched by the user.

When certain target applications are launched by the user, and this includes not only financial applications but also MFA applications such as Google’s Authenticator, the malware can grab all the content of the interface in a programmatic way. The content then is sent to the threat actor’s command & control center, for further processing and identification for the next actions in the operation.

03-17 08:32:45.041 4505 4505 E uyzdrrhtqm : packageApp{com.google.android.apps.nexuslauncher} strText{apps list} className{com.google.android.apps.nexuslauncher.nexuslauncheractivity} 03-17 08:32:45.083 4505 4505 E uyzdrrhtqm : packageApp{com.google.android.apps.nexuslauncher} strText{apps list} className{com.google.android.apps.nexuslauncher.nexuslauncheractivity} 03-17 08:46:31.913 4505 4505 E uyzdrrhtqm : nodeInfo == null 03-17 08:46:31.916 4505 4505 E uyzdrrhtqm : nodeInfo == null 03-17 08:46:31.931 4505 4505 E uyzdrrhtqm : nodeInfo == null 03-17 08:46:31.931 4505 4505 E uyzdrrhtqm : nodeInfo == null 03-17 08:46:31.941 4505 4505 E uyzdrrhtqm : packageApp{com.google.android.apps.authenticator2} strText{} className{android.widget.framelayout} 03-17 08:46:31.960 4505 4505 E uyzdrrhtqm : nodeInfo == null 03-17 08:46:36.049 4505 4505 E uyzdrrhtqm : packageApp{com.google.android.apps.authenticator2} strText{google authenticator} className{com.google.android.apps.authenticator.authenticatoractivity} 03-17 09:00:38.899 4505 4505 E uyzdrrhtqm : packageApp{com.google.android.apps.authenticator2} strText{how it works} className{com.google.android.apps.authenticator.howitworks.howitworksactivity} 03-17 09:00:45.735 4505 4505 E uyzdrrhtqm : packageApp{com.google.android.apps.authenticator2} strText{add an account} className{com.google.android.apps.authenticator.enroll2sv.wizard.addaccountactivity} 03-17 09:00:52.138 4505 4505 E uyzdrrhtqm : packageApp{com.google.android.apps.authenticator2} strText{enter account details} className{com.google.android.apps.authenticator.otp.enterkeyactivity} 03-17 09:00:53.729 4505 4505 E uyzdrrhtqm : packageApp{com.google.android.inputmethod.latin} strText{} className{android.inputmethodservice.softinputwindow} 03-17 09:00:53.743 4505 4505 E uyzdrrhtqm : nodeInfo == null 03-17 09:04:40.188 4505 4505 E uyzdrrhtqm : packageApp{com.google.android.googlequicksearchbox} strText{} className{android.widget.framelayout} 03-17 09:04:40.206 4505 4505 E uyzdrrhtqm : nodeInfo == null 03-17 09:04:40.815 4505 4505 E uyzdrrhtqm : packageApp{com.google.android.apps.nexuslauncher} strText{home screen 1 of 2} className{com.google.android.apps.nexuslauncher.nexuslauncheractivity} 03-17 09:04:41.153 4505 4505 E uyzdrrhtqm : packageApp{com.google.android.apps.nexuslauncher} strText{home screen 1 of 2} className{com.google.android.apps.nexuslauncher.nexuslauncheractivity} 03-17 09:04:52.391 4505 4505 E uyzdrrhtqm : nodeInfo == null

Malware’s log records with content from the user’s applications

Moreover, the powerful Accessibility Services capabilities can be abused to bypass other types of MFA methods. In theory, the malicious application should be able to interact with a Push-to-Accept notification and accept an authentication factor prompt in a programmatic way. The options are almost limitless provided that the malware has access to interact with the victim’s user interface.

Additional reports highlighted the fact that some MFA applications, namely Google Authenticator and Microsoft Authenticator, don’t prevent the user or other applications from taking screenshots when OTP codes are being displayed. While this can be indeed a potential risk worth fixing, by means of using the FLAG_SECURE option, it’s unrelated to the mechanism that Cerberus has developed for grabbing OTP codes.

As already mentioned, Cerberus was one of the first malware pieces reported using this technique to specifically target MFA applications, but not the only one. For example, TrickBot was recently found using the same techniques. We believe this technique will continue to grow in use until a more robust prevention or mitigation mechanism is put in place as part of the Android ecosystem.

Impact on Identity Security

The next question is then, what does this mean for identity security? Should we begin to dispose of all MFA mobile applications and start thinking of newer mechanisms to deliver additional authentication methods?

Although we believe identity security should be all about frictionless user experiences, ranging for advanced and risk-based adaptive authentication to password-less experiences, the fact that malware has developed stronger mechanisms to bypass MFA doesn’t mean that those authentication strategies are inappropriate. MFA mobile applications will continue to be crucial, in the short-term, for a large set of use cases. And the fact that malicious malware has already infected user’s devices and can access the devices doesn’t constitute a strong enough case against them.

Instead, we think security and identity programs should be comprehensive and contemplate not only the need to deliver access methods to the users but also how to secure those delivery mechanisms. Integration with Mobile Device Management (MDM) solutions, strong vetting of applications before installation, device monitoring and security training and awareness are all part of extensive security programs that should be considered according to the maturity and risk profile of each organization. Risk-based and adaptive authentication solutions that ponder contextual, behavioral and threat-related attributes are part of the mix as well, by relying less on the user interaction and explicit confirmation and providing smoother experiences.

These recent developments also reinforce that threat actors are innovating, and their innovation cycles are quite short. Security solutions need to keep up with those innovation cycles and having a threat-aware mindset is imperative to come out on top of adversaries and their operations.

Final Thoughts

The recent developments on mobile malware studied in this article are just a small sample of the type of sophisticated attacks that adversaries are implementing among their playbooks. Coordinating and designing identity security solutions require understanding these techniques and the way threat actors run their operations.

Recommended strategies are two-fold. On one side, focus on the malware entry points: include mobile topics on your organization’s security awareness training, reduce and track mobile phishing attempts, monitor users’ devices to make sure they are running the latest operating system and device versions and that they are not installing or side-loading applications not approved by the organization.

On the other side, and as a longer-term strategy, begin to implement access workflows and experiences that do not rely only on the sole user intervention but instead analyzes contextual, behavioral and threat indicators and attributes to make authentication and authorization decisions.

If you have questions, comments or feedback about any of these topics, reach out to me on Twitter at @martingalloar or email our Innovation Labs using labs@secureauth.com!

Appendix

References

• https://www.zdnet.com/article/android-malware-can-steal-google-authenticator-2fa-codes/
• https://www.pcmag.com/news/android-malware-can-steal-2fa-codes-from-google-authenticator-app
• https://www.threatfabric.com/blogs/2020_year_of_the_rat.html
• https://enterprise.verizon.com/resources/reports/mobile-security-index/
• https://www.wandera.com/mobile-phishing-report/
• https://thehackernews.com/2019/08/cerberus-android-banking-trojan.html
• https://www.threatfabric.com/blogs/cerberus-a-new-banking-trojan-from-the-underworld.html
• https://www.zdnet.com/article/google-could-have-fixed-2fa-code-stealing-flaw-in-authenticator-app-years-ago/

Indicators of Compromise