While analysts figure out new methodologies for analysing malware and users begin to understand how all this works, cybercriminals are seeking new ways to hide in phones and compromise devices, says ESET Southern Africa.
The convoluted tricks used to increase the effectiveness of their attacks can be grouped into two distinct categories: First, Social Engineering strategies that seek to confuse users; and second, sophisticated technical mechanisms that try to obstruct malware detection and analysis.
This article summarises some of the common behaviours of malicious Android code over the last few years.
Social engineering is used in a variety of ways to breach Android devices:
Use fraudulent accounts in the Play Store to distribute malware
Malware in the official Google store never stops appearing. For cybercriminals, sneaking their malicious applications into the marketplace of genuine apps is a huge victory, as they can reach many more potential victims, thus having an almost rock-solid guarantee of more infections.
What’s more, the fake developer accounts used to spread insecure or malicious apps try to look as similar as possible to real accounts, to dupe unsuspecting users who end up getting confused by them. In a recent example of this, researchers discovered a fake app for updating WhatsApp that used a Unicode character trick to give the impression of being distributed through the official account.
Take advantage of commemorative dates and scheduled app release dates
A common practice in the world of cybercrime is to make malware look like versions of apps – games, mostly – that have gained sudden popularity, which are either scheduled for release or are not available in official stores for certain countries. This happened with Pokémon GO, Prisma and Dubsmash, adding hundreds of thousands of infections worldwide.
Tapjacking and overlay windows
Tapjacking is a technique that involves capturing a user’s screen taps by displaying two superimposed apps. So, victims believe that they are tapping on the app that they are seeing, but they are actually tapping on the underlying app, which remains hidden from view.
Another similar strategy, which is widely used in spyware for credential theft in Android, is overlay windows. In this scam, the malware continually tracks the app that the user is using, and when it coincides with a certain objective app, it displays its own dialog box that looks just like the legitimate app, requesting credentials from the user.
Camouflaged among system apps
By far, the easiest way for malicious code to hide on a device is to pass itself off as a system app and go as unnoticed as possible. Malpractices such as deleting the app icon once the installation is finished or using names, packages and icons of system apps and other popular apps to compromise a device are strategies that are emerging in code like this banking Trojan that passed itself off as Adobe Flash Player to steal credentials.
Simulating system and security apps to request administrator permissions
Since Android is structured to limit app permissions, a lot of malicious code needs to request administrator permissions to implement its functionality correctly. And granting this permission makes it more difficult to uninstall the malware.
Being camouflaged as security tools or system updates gives cybercriminals certain advantages. In particular, it allows them to shield themselves behind a trusted developer, and consequently users do not hesitate to authorize the app to access administrative functions.
Security certificates that simulate true data
The security certificate used to sign an APK can also be used to determine if an app has been altered. And while most cybercriminals use generic text strings when issuing a certificate, many go to the trouble of feigning data that correspond to the data used by the developer, going one step further in their efforts to confuse users who carry out these checks.
Hackers also use a number of techniques for complicating analysis:
Multiple functionalities in the same code
A trend that has been gaining ground in recent years in the mobile world is to combine what used to be different types of malware into a single executable. LokiBot is one example of this, which is a banking Trojan that tries to go unnoticed for as long as possible in order to steal information from a device; however, if the user tries to remove the administrator’s permissions to uninstall it, it activates its ransomware feature by encrypting the device’s files.
The use of droppers and downloaders, i.e., embedding malicious code inside another APK or downloading it from the internet, is a strategy that is not only limited to malware for laptops and computers, but is also universally used by malicious mobile code writers.
As the then-known Google Bouncer (now rebranded as Google Play Protect) complicated cybercriminals’ ability to upload malware to the official store, the attackers chose to include this type of behaviour to try to bypass controls … and it worked! Well, for a while at least.
Since then, these two forms of malware coding have been added to the portfolio of most-used malicious techniques.
Multiple programming languages and volatile code
New multiplatform development frameworks and new programming languages are emerging all the time. What better way to mislead a malware analyst than to combine languages and development environments, such as designing apps with Xamarin or using Lua code to execute malicious commands. This strategy changes the final architecture of the executable, and adds levels of complexity.
Some attackers add to this combo by using dynamic script loading or portions of code that are downloaded from remote servers and deleted after use. So once the server has been removed by the cybercriminal, it is not possible to know exactly what actions the code performed on the device.
Samples with these characteristics began to appear towards the end of 2014, when researchers published this particularly complex malware analysis.
An alternative for complicating the analysis of a sample is to divide the malicious functionality into a set of apps that are capable of interacting with each other. By doing so, each app has a subset of permissions and malicious functionality, and they then interact with each other to fulfil a further purpose. Moreover, for analysts to understand the true function of the malware, they must have access to all the individual apps as if they were pieces of a puzzle.
And while this is not a commonly-used strategy, there have already been samples that exhibit this type of behaviour, as a publication on Virus Bulletin recently demonstrated.
Covert channels and new communication mechanisms
To communicate with a C&C server or other malicious apps, malware needs to transfer information. This can be done via traditional open channels or hidden channels (personalized communication protocols, brightness intensity, wake locks, CPU utilization, free space in memory, sound or vibration levels, and accelerometers, among others).
Furthermore, in recent months we have seen how cybercriminals are using social networks to transfer C&C messages, such as Twitoor, the botnet that uses Twitter accounts to send commands.
Other anti-analysis techniques
The use of packaging, anti-emulation, anti-debugging, encryption, and obfuscation, among other evasion techniques, is very common in malware for Android. To get around these types of protections, it is possible to use hooking of functions, perhaps through apps such as Frida.
It is also possible to use analysis environments that try to dodge these controls by default, such as MobSF–which includes some anti-emulation techniques, Inspeckage–where, for example, flat text strings can be seen before and after being encrypted, together with the keys used, or AppMon.