As stated in the executive summary of the Corporate SOME Setup and Management Guide published by the Directorate General of Communications under the Ministry of Transport, Maritime Affairs, and Communications of the Republic of Turkey in 2014, Corporate Cyber Incident Response Teams (SOME) are crucial structures in mitigating cyber incidents and preventing or reducing potential damage.
SOMEs, which are equipped not only with SIEM engineers and penetration testing experts but also with security specialists skilled in malware analysis, are generally one step ahead of those without such expertise. This makes them stronger in terms of enhancing institutional defense and protecting their clients. (One-person, “superhero” teams of SOME are excluded from this comparison.)
In the critical infrastructure sectors, such as the financial sector, it is vital for banks and corporate SOMEs to closely monitor banking malware, whether it’s mobile or not. By monitoring the evolution of banking malware, a bank may foresee potential future threats and take the necessary precautions.
Beyond mobile banking malware, the rise of next-generation phishing attacks, many of which are also carried out through mobile malware, further emphasizes the need for security experts who specialize in mobile malware analysis.
In mid-2015, banks were faced with an Android malware targeting their customers, which was thoroughly analyzed by Bakır EMRE.
By the middle of 2016, it became evident that the developers behind this Android malware had added a communication feature via TOR. Moreover, they had created counterfeit pages for 27 out of 51 banks operating in Turkey (as of 2015) on their web pages, with addresses like banka.mobilsubeyukle.com.
While analyzing the malware, I noticed not only the use of Turkish function names but also the presence of another function named isvm. The fact that this function wasn’t called by any other function (xref) signaled to me that we might encounter this function in future versions. Upon inspecting the function, I found that it was designed to detect Android emulators, specifically the ones commonly used by security experts during malware analysis, such as the Android Emulator and Genymotion.
Android Anti Anti-Emulator
My first step was to install the Android Studio version distributed for free by Google to develop Android applications. I then modified the isvm function, which I had decompiled using jD-GUI, to output a result like “Are you in VM? Result: true” when it detected an emulator. Afterward, I wrote a script that would execute this code inside an emulator.
The relevant code in the malware detected emulators by checking specific properties like Build.PRODUCT, Build.FINGERPRINT, Build.MANUFACTURER, Build.MODEL, Build.BRAND, and Build.DEVICE. So, I began researching how to modify these values in the Genymotion emulator, which was running a Custom Phone – 5.1.0 – API 22 image.
I soon discovered that these values were located in the /system/build.prop file. Since the images in Genymotion run with root privileges, I installed the Root Explorer app and began removing the values used for detection from the /system/build.prop file. After saving the changes, I restarted the emulator and ran the isvm detection code again. This time, I was able to bypass the emulator detection by simply modifying a small setting on the system (Are you in VM? Result: false) without having to engage with IDA or other debugging tools.
With this modification, I successfully evaded the emulator detection, which I had anticipated would be a challenging hurdle in the analysis.
