In this final blog in the Rootnik series we will finish our analysis of this new variant. Read Part 2 here
Let’s start by looking into the script shell rsh.
Through our investigation we are able to see how the script shell works:
The following is the content of the file .ir.
The following is the content of the file .dg.
The following is the content of the file a.xml.
I next analyzed the ELF file .rainin in the folder /system/xbin/. It’s used to inject the library libsoon.so into the processes vold, netd, as well as zygote.
Figure 1. The function injecting libsoon.so in process
The following is the key code snippet in the function sub_94C8(int a1, const char *a2, char *a3, char *a4).
Figure 2. The key code snippet in the function sub_94C8
The following is the log file after executing the ELF file /system/xbin/.rainin
Figure 3. The log file after executing /system/xbin/.rainin
When the .so injection is successful, it can invoke the function solib_entry in libsoon.so.
Figure 4. The function solib_entry in libsoon.so
The definition of the function checkInstallRecoveryEtc() is shown below.
Figure 5. The function checkInstallRecoveryEtc()
It checks the mode of some binary files as well as some installed apps. It then restores InstallRecovery script, and checks to see if the SU daemon is running. Finally, it checks to see if the app “com.fly.me.ssp.be” has been installed. If not, it could run this app.
The ELF file /system/bin/.author is a su binary. The following is its usage:
Figure 6. The usage of /system/bin/.author
As shown in Tables 1 and 2 in Part II of this blog series, the malware app is able to launch some activities in the installed app. Combining them with the installed apps in script shell rsh, we have listed these installed apps as follows:
Table 1. The list of installed apps
From column labeled “Detection” you can see that Fortinet’s AV engine has detected and identified them as malware.
You can also see that most of them were installed in the system app folder /system/priv-app/. The other two apps were installed in the folder /data/app/ through the command “pm install”.
The APK files listed in Table 1 can be generated by two methods: via http request and by being hard-coded. Regardless of whether the hard-coded or http request method is used, the data generated is decrypted. The two decryption algorithms used are shown in the Appendix at the end of this blog.
Additionally, we also found that more apps (including, but not limited to the following) had been installed in the folder /system/priv-app/.
Figure 7. Apps installed in folder /system/priv-app/ by the malware
We also found that a large number of apps (including, but not limited to the following) had been installed in the folder /data/app/.
Figure 8. Apps installed in folder /data/app/ by the malware
The Rootnik malware performed a number of malicious behaviors. These include, but are not limited to the following:
In addition to gaining root privileges on the device, the rootnik malware promotes apps and ads to generate revenue for its creator. Its app and ad promotion is especially aggressive and annoying to the user. The following are some screenshots of its app promotion:
Figure 9. The screenshots of app promotion
The following is the screenshot of normal app installation and silent app installation.
Figure 10. The screenshots of normal and silent app installations
The malware pushes a notification and induces the user to click it.
Figure 11. Push notification
The malware can send SMS messages to aspecific subscription number and then delete it in the SMS box. It can also send an SMS message through adb command.
We found that many files and folders were also downloaded in folder /sdcard/. They include apk files, pictures, log files, etc. These files are generated by the installed apps, and some of them perform malicious behaviors.
Figure 12. Files and folders dropped into folder /sdcard/
Finally, I drew the following workflow diagram of how the new Android Rootnik variant works.
Figure 13. An overview of the Android Rootnik malware’s workflow
The malware sample is detected by Fortinet Antivirus signature Android/Rootnik.AE!tr.
The traffic communicating with remote C2 server can be detected by Fortinet IPS signature Android.Rootnik.Malware.C2.
From the analysis, we can see that this new Rootnik variant is able to disguise itself as a legal app. The developer of the malware app was able to repackage a legal app from Google Play and insert malicious codes into it. This disguise can trick even careful users.
Additionally, this new variant is rather powerful and uses advanced anti-debugging techniques to prevent reversing engineering, as well as different types of encryption for files and strings. The malware also uses some open-sourced Android root exploit tools and the MTK root scheme from dashi root tool to gain root access on the Android device. The root exploits can be downloaded from a remote http server. It’s also easy for the developer to update the root scheme of this malware and extend its functionality. Finally, after successfully gaining root privileges on the device, the rootnik malware can perform a variety of malicious operations, including app and ad promotion, silent app installation, and pushing notifications and sending SMS messages, etc.
Rootnik Malware Sample
Package Name: net.gotsun.android.wifi_configuration
Additional APK files dropped into system partition by Rootnik malware
Package Name: com.para.android.power
Package Name: com.facebook.application
Package Name: com.android.service.power.on
Package Name: com.android.fk.json.tool
Package Name: com.fly.me.ssp.be
Package Name: org.app.info.grate
Package Name: com.android.tools.receiver
Package Name: com.android.upon.hash
Package Name: com.setting.dysdtool
Package Name: com.sang.you.mima.yuanhou
Package Name: com.music.cloud.app.player
Package Name: com.android.shopping.eupdate
The decryption program for the hard-coded method
The decryption program for the http request method