Moreover , incoming traffic from the C & C server began to use gzip compression , and the top-level domain for all C & Cs was .com : Since December 2016 , the changes in C & C communication methods have affected only how the relative path in the URL is generated : the pronounceable word was replaced by a rather long random combination of letters and numbers , for example , “ ozvi4malen7dwdh ” or “ f29u8oi77024clufhw1u5ws62 ” .


At the time of writing this article , no other significant changes in Asacub ’ s network behavior had been observed : The origin of Asacub It is fairly safe to say that the Asacub family evolved from Trojan-SMS.AndroidOS.Smaps .


Communication between both Trojans and their C & C servers is based on the same principle , the relative addresses to which Trojans send network requests are generated in a similar manner , and the set of possible commands that the two Trojans can perform also overlaps .


What ’ s more , the numbering of Asacub versions is a continuation of the Smaps system .


The main difference is that Smaps transmits data as plain text , while Asacub encrypts data with the RC4 algorithm and then encodes it into base64 format .


Let ’ s compare examples of traffic from Smaps and Asacub — an initializing request to the C & C server with information about the infected device and a response from the server with a command for execution : Smaps request Asacub request Decrypted data from Asacub traffic : { “ id ” : ” 532bf15a-b784-47e5-92fa-72198a2929f5″ , ” type ” : ” get ” , ” info ” : ” imei:365548770159066 , country : PL , cell : Tele2


, android:4.2.2 , model : GT-N5100 , phonenumber : +486679225120 , sim:6337076348906359089f , app : null , ver:5.0.2″ } Data sent to the server [ { “ command ” : ” sent & & & ” , ” params ” : { “ to ” : ” +79262000900″ , ” body ” : ” \u0410\u0412\u0422\u041e\u041f\u041b\u0410\u0422\u0415\u0416


1000 50″ , ” timestamp ” : ” 1452272572″ } } , { “ command ” : ” sent & & & ” , ” params ” : { “ to ” : ” +79262000900″ , ” body ” : ” BALANCE ” , ” timestamp ” : ” 1452272573″ } } ] Instructions received from the server A comparison can also be made of the format in which Asacub and Smaps forward incoming SMS ( encoded with the base64 algorithm ) from the device to the C & C server : Smaps


format Asacub format Decrypted data from Asacub traffic : { “ data ” : ” 2015:10:14_02:41:15″ , ” id ” : ” 532bf15a-b784-47e5-92fa-72198a2929f5″ , ” text ” : ” SSB0aG91Z2h0IHdlIGdvdCBwYXN0IHRoaXMhISBJJ20gbm90IGh1bmdyeSBhbmQgbmU= ” , ” number ” : ” 1790″ , ” type


” : ” load ” } Propagation The banking Trojan is propagated via phishing SMS containing a link and an offer to view a photo or MMS .


The link points to a web page with a similar sentence and a button for downloading the APK file of the Trojan to the device .


The Trojan download window Asacub masquerades under the guise of an MMS app or a client of a popular free ads service .


We came across the names Photo , Message , Avito Offer , and MMS Message .


App icons under which Asacub masks itself The APK files of the Trojan are downloaded from sites such as mmsprivate [ .


] site , photolike [ .


] fun , you-foto [ .


] site , and mms4you [ .


] me under names in the format : photo_ [ number ] _img.apk , mms_ [ number ] _img.apk avito_ [ number ] .apk , mms.img_ [ number ] _photo.apk , mms [ number ] _photo.image.apk , mms [ number ] _photo.img.apk , mms.img.photo_ [ number ] .apk , photo_ [ number ] _obmen.img.apk .


For the Trojan to install , the user must allow installation of apps from unknown sources in the device settings .


Infection During installation , depending on the version of the Trojan , Asacub prompts the user either for Device Administrator rights or for permission to use AccessibilityService .


After receiving the rights , it sets itself as the default SMS app and disappears from the device screen .


If the user ignores or rejects the request , the window reopens every few seconds .


The Trojan requests Device Administrator rights The Trojan requests permission to use AccessibilityService After installation , the Trojan starts communicating with the cybercriminals ’ C & C server .


All data is transmitted in JSON format ( after decryption ) .


It includes information about the smartphone model , the OS version , the mobile operator , and the Trojan version .


Let ’ s take an in-depth look at Asacub 5.0.3 , the most widespread version in 2018 .


Structure of data sent to the server : To begin with , the Trojan sends information about the device to the server : In response , the server sends the code of the command for execution ( “ command ” ) , its parameters ( “ params ” ) , and the time delay before execution ( “ waitrun ” in milliseconds ) .


List of commands sewn into the body of the Trojan : Command code Parameters Actions 2 – Sending a list of contacts from the address book of the infected device to the C & C server 7 “ to ” : int Calling the specified number 11 “ to ” : int , “ body ” : string Sending an SMS with the specified text to the specified number 19 “ text ” : string , “ n ” : string Sending SMS with the specified text to numbers from the address book of the infected device , with the name of the addressee from the


address book substituted into the message text 40 “ text ” : string Shutting down applications with specific names ( antivirus and banking applications ) The set of possible commands is the most significant difference between the various flavors of Asacub .


In the 2015-early 2016 versions examined in this article , C & C instructions in JSON format contained the name of the command in text form ( “ get_sms ” , “ block_phone ” ) .


In later versions , instead of the name of the command , its numerical code was transmitted .


The same numerical code corresponded to one command in different versions , but the set of supported commands varied .


For example , version 9.0.7 ( 2017 ) featured the following set of commands : 2 , 4 , 8 , 11 , 12 , 15 , 16 , 17 , 18 , 19 , 20 .


After receiving the command , the Trojan attempts to execute it , before informing C & C of the execution status and any data received .


The “ id ” value inside the “ data ” block is equal to the “ timestamp ” value of the relevant command : In addition , the Trojan sets itself as the default SMS application and , on receiving a new SMS , forwards the sender ’ s number and the message text in base64 format to the cybercriminal : Thus , Asacub can withdraw funds from a bank card linked to the phone by sending SMS for the transfer of funds to another account using the number of the card or mobile phone .


Moreover , the Trojan intercepts SMS from the bank that contain one-time passwords and information about the balance of the linked bank card .


Some versions of the Trojan can autonomously retrieve confirmation codes from such SMS and send them to the required number .


What ’ s more , the user can not check the balance via mobile banking or change any settings there , because after receiving the command with code 40 , the Trojan prevents the banking app from running on the phone .


User messages created by the Trojan during installation typically contain grammatical and spelling errors , and use a mixture of Cyrillic and Latin characters .


The Trojan also employs various obfuscation methods : from the simplest , such as string concatenation and renaming of classes and methods , to implementing functions in native code and embedding SO libraries in C/C++ in the APK file , which requires the use of additional tools or dynamic analysis for deobfuscation , since most tools for static analysis of Android apps support only Dalvik bytecode .


In some versions of Asacub , strings in the app are encrypted using the same algorithm as data sent to C & C , but with different keys .


Example of using native code for obfuscation Examples of using string concatenation for obfuscation Example of encrypting strings in the Trojan Asacub distribution geography Asacub is primarily aimed at Russian users : 98 % of infections ( 225,000 ) occur in Russia , since the cybercriminals specifically target clients of a major Russian bank .


The Trojan also hit users from Ukraine , Turkey , Germany , Belarus , Poland , Armenia , Kazakhstan , the US , and other countries .


Conclusion The case of Asacub shows that mobile malware can function for several years with minimal changes to the distribution scheme .


It is basically SMS spam : many people still follow suspicious links , install software from third-party sources , and give permissions to apps without a second thought .


At the same time , cybercriminals are reluctant to change the method of communication with the C & C server , since this would require more effort and reap less benefit than modifying the executable file .


The most significant change in this particular Trojan ’ s history was the encryption of data sent between the device and C & C .


That said , so as to hinder detection of new versions , the Trojan ’ s APK file and the C & C server domains are changed regularly , and the Trojan download links are often one-time-use .


IOCs C & C IP addresses : 155.133.82.181 155.133.82.240 155.133.82.244 185.234.218.59 195.22.126.160 195.22.126.163 195.22.126.80 195.22.126.81 5.45.73.24 5.45.74.130 IP addresses from which the Trojan was downloaded : 185.174.173.31 185.234.218.59 188.166.156.110 195.22.126.160 195.22.126.80 195.22.126.81


195.22.126.82 195.22.126.83 SHA256 : 158c7688877853ffedb572ccaa8aa9eff47fa379338151f486e46d8983ce1b67 3aedbe7057130cf359b9b57fa533c2b85bab9612c34697585497734530e7457d f3ae6762df3f2c56b3fe598a9e3ff96ddf878c553be95bacbd192bd14debd637 df61a75b7cfa128d4912e5cb648cfc504a8e7b25f6c83ed19194905fef8624c8


31edacd064debdae892ab0bc788091c58a03808997e11b6c46a6a5de493ed25d 87ffec0fe0e7a83e6433694d7f24cfde2f70fc45800aa2acb8e816ceba428951 eabc604fe6b5943187c12b8635755c303c450f718cc0c8e561df22a27264f101 Kernel Backdoor found in Gadgets Powered by Popular Chinese ARM


Maker May 12 , 2016 Mohit Kumar How to Hack an Android device ?


It is possibly one of the most frequently asked questions on the Internet .


Although it 's not pretty simple to hack Android devices and gadgets , sometimes you just get lucky to find a backdoor access .


Thanks to Allwinner , a Chinese ARM system-on-a-chip maker , which has recently been caught shipping a version of Linux Kernel with an incredibly simple and easy-to-use built-in backdoor .


Chinese fabless semiconductor company Allwinner is a leading supplier of application processors that are used in many low-cost Android tablets , ARM-based PCs , set-top boxes , and other electronic devices worldwide .


Simple Backdoor Exploit to Hack Android Devices All you need to do to gain root access of an affected Android device is… Send the text " rootmydevice '' to any undocumented debugging process .


The local privileges escalation backdoor code for debugging ARM-powered Android devices managed to make its way in shipped firmware after firmware makers wrote their own kernel code underneath a custom Android build for their devices , though the mainstream kernel source is unaffected .


The backdoor code is believed to have been left by mistake by the authors after completing the debugging process .


For exploiting this issue , any process running with any UID can be converted into root easily by simply using the following command : echo " rootmydevice '' > /proc/sunxi_debug/sunxi_debug The Linux 3.4-sunxi kernel was originally designed to support the Android operating system on Allwinner ARM for tablets , but later it was used to port Linux to many Allwinner processors on boards like Banana Pi micro-PCs , Orange Pi , and other devices .


At the forum of the Armbian operating system , a moderator who goes by the name Tkaiser noted that the backdoor code could remotely be exploitable " if combined with networked services that might allow access to /proc .


'' This security hole is currently present in every operating system image for A83T , H3 or H8 devices that rely on kernel 3.4 , he added .


This blunder made by the company has been frustrating to many developers .


Allwinner has also been less transparent about the backdoor code .


David Manouchehri released the information about the backdoor through its own Github account ( Pastebin ) and then apparently deleted it .


Mobile Malware Evolution : 2013 24 FEB 2014 The mobile malware sector is growing rapidly both technologically and structurally .


It is safe to say that today ’ s cybercriminal is no longer a lone hacker but part of a serious business operation .


There are various types of actors involved in the mobile malware industry : virus writers , testers , interface designers of both the malicious apps and the web pages they are distributed from , owners of the partner programs that spread the malware , and mobile botnet owners .


This division of labor among the cybercriminals can also be seen in the behavior of their Trojans .


In 2013 , there was evidence of cooperation ( most probably on a commercial basis ) between different groups of virus writers .


For example , the botnet Trojan-SMS.AndroidOS.Opfake.a , in addition to its own activity , also spread Backdoor.AndroidOS.Obad.a by sending spam containing a link to the malware to the victim ’ s list of contacts .


It is now clear that a distinct industry has developed and is becoming more focused on extracting profits , which is clearly evident from the functionality of the malware .


2013 in figures A total of 143,211 new modifications of malicious programs targeting mobile devices were detected in all of 2013 ( as of January 1 , 2014 ) .


In 2013 , 3,905,502 installation packages were used by cybercriminals to distribute mobile malware .


Overall in 2012-2013 we detected approximately 10,000,000 unique malicious installation packages : Different installation packages can install programs with the same functionality that differ only in terms of the malicious app interface and , for instance , the content of the text messages it spreads .


Android remains a prime target for malicious attacks .


98.05 % of all malware detected in 2013 targeted this platform , confirming both the popularity of this mobile OS and the vulnerability of its architecture .


Most mobile malware is designed to steal users ’ money , including SMS-Trojans , and lots of backdoors and Trojans .


Over the year , the number of mobile malware modifications designed for phishing , the theft of credit card information and money increased by a factor of 19.7 .


In 2013 , Kaspersky Lab mobile products prevented 2,500 infections by banking Trojans .


Methods and techniques 2013 not only saw a radical increase in output from mobile virus writers but also saw them actively applying methods and technologies that allowed cybercriminals to use their malware more effectively .


There were several distinct areas where mobile malware underwent advances .


Distribution Cybercriminals made use of some exceptionally sophisticated methods to infect mobile devices .


Infecting legal web resources help spread mobile malware via popular websites .


More and more smartphone and tablet owners use their devices to access websites , unaware that even the most reputable resources can be hacked .


According to our data , 0.4 % of the websites visited by users of our products were compromised sites .


Distribution via alternative app stores .


In Asia there are numerous companies producing Android-based devices and Android apps , and many of them offer users their own app stores containing programs that can not be found in Google Play .


The purely nominal control over the applications uploaded to these stores means attackers can conceal Trojans in apps made to look like innocent games or utilities .


Distribution via botnets .


As a rule , bots self-proliferate by sending out text messages with a malicious link to addresses in the victim ’ s address book .


We also registered one episode of mobile malware spreading via a third-party botnet .


Resistance to anti-malware protection The ability of malicious software to operate continuously on the victim ’ s mobile device is an important aspect of its development .


The longer a Trojan “ lives ” on a smartphone , the more money it will make for the owner .


This is an area where virus writers are actively working , resulting in a large number of technological innovations .


Criminals are increasingly using obfuscation , the deliberate act of creating complex code to make it difficult to analyze .


The more complex the obfuscation , the longer it will take an antivirus solution to neutralize the malicious code .


Tellingly , current virus writers have mastered commercial obfuscators .


This implies they have made considerable investments .


For example , one commercial obfuscator , which cost €350 , was used for Trojans and Opfak.bo Obad.a Android vulnerabilities are used by criminals for three reasons : to bypass the code integrity check when installing an application ( vulnerability Master Key ) ; to enhance the rights of malicious applications , considerably extending their capabilities ; and to make it more difficult to remove malware .


For example , Svpeng uses a previously unknown vulnerability to protect itself from being removed manually or by the antivirus program .


Cybercriminals also exploit the Master Key vulnerability and have learned to embed unsigned executable files in Android installation packages .


Digital signature verification can be bypassed by giving the malicious file exactly the same name as a legitimate file and placing it on the same level in the archive .


The system verifies the signature of the legitimate file while installing the malicious file .


Unfortunately , there is a specific feature of Android vulnerabilities that means it is only possible to get rid of them by receiving an update from the device manufacturers .


However , many users are in no hurry to update the operating systems of their products .


If a smartphone or tablet was released more than a year ago , it is probably no longer supported by the manufacturer and patching of vulnerabilities is no longer provided .


In that case , the only help comes from an antivirus solution , for example , Kaspersky Internet Security for Android .


Embedding malicious code in legitimate programs helps conceal infections from the victim .


Of course , this does not mean the digital signature of the software developer can be used .


However , due to the absence of certification centers verifying the digital signatures of Android programs , nothing prevents criminals from adding their own signature .


As a result , a copy of Angry Birds installed from an unofficial app store or downloaded from a forum could easily contain malicious functionality .


Capabilities and functionality In 2013 , we detected several technological innovations developed and used by criminals in their malicious software .


Below are descriptions of some of the most interesting .


Control of malware from a single center provides maximum flexibility .


Botnets can make considerably more money than autonomous Trojans .


It comes as no surprise then that many SMS-Trojans include bot functionality .


According to our estimates , about 60 % of mobile malware are elements of both large and small mobile botnets .


By using Google Cloud Messaging botnet owners can operate without a C & C server , thus eliminating the threat of the botnet being detected and blocked by law enforcement authorities .


Google Cloud Messaging is designed to send short message ( up to 4 KB ) to mobile devices via Google services .


The developer simply has to register and receive a unique ID for his applications .


The commands received via GCM can not be blocked immediately on an infected device .


We have detected several malicious programs using GCM for command and control – the widespread Trojan-SMS.AndroidOS.FakeInst.a , Trojan-SMS.AndroidOS.Agent.ao , and Trojan-SMS.AndroidOS.OpFake.a among others .


Google is actively combating this use of the service , responding quickly to reports from antivirus companies and blocking the IDs of cybercriminals .


Attacks on Windows XP allows mobile malware to infect a PC after connecting a smartphone or tablet .


In early 2013 we detected two identical applications on Google Play that were allegedly designed for cleaning the operating system of Android-based devices from unnecessary processes .


In fact , the applications are designed to download the autorun.inf file , an icon file and the win32-Trojan file , which the mobile malicious program locates in the root directory of an SD card .


On connecting a smartphone in the USB drive emulation mode to a computer running Windows XP , the system automatically starts the Trojan ( if AutoPlay on the external media is not disabled ) and is infected .


The Trojan allows the criminals to remotely control the victim ’ s computer and is capable of recording sound from a microphone .


We would like to emphasize that this method of attack only works on Windows XP and Android versions prior to 2.2 .


The most advanced mobile malicious programs today are Trojans targeting users ’ bank accounts – the most attractive source of criminal earnings .


Trend of the year : mobile banking Trojans 2013 was marked by a rapid rise in the number of Android banking Trojans .


The cyber industry of mobile malware is becoming more focused on making profits more effectively , i.e. , mobile phishing , theft of credit card information , money transfers from bank cards to mobile phones and from phones to the criminalas ’ e-wallets .


Cybercriminals have become obsessed by this method of illegal earnings : at the beginning of the year we knew only 67 banking Trojans , but by the end of the year there were already 1321 unique samples .


Kaspersky Lab mobile products prevented 2,500 infections by banking Trojans .


mobile_treats_2013_04s The number of mobile banking Trojans in our collection Mobile banking Trojans can run together with Win-32 Trojans to bypass the two-factor authentication – mTAN theft ( the theft of banking verification codes that banks send their customers in SMS messages ) .


However , in 2013 , autonomous mobile banking Trojans developed further .


Currently , such Trojans attack a limited number of bank customers , but it is expected that cybercriminals will invent new techniques that will allow them to expand the number and the geography of potential victims .


mobile_treats_2013_05s Infections caused by mobile banking programs Today , the majority of banking Trojan attacks affect users in Russia and the CIS .


However , this situation will not last long : given the cybercriminals ’ interest in user bank accounts , the activity of mobile banking Trojans is expected to grow in other countries in 2014 .


As mentioned above , banking Trojans are perhaps the most complex of all mobile threats , and Svpeng is one of the most striking examples .


Svpeng In mid-July , we detected Trojan-SMS.AndroidOS.Svpeng.a which , unlike its SMS Trojan counterparts , is focused on stealing money from the victiim ’ s bank account rather than from his mobile phone .


It can not act independently and operates strictly in accordance with commands received from the C & C server .


This malicious program spreads via SMS spam and from compromised legitimate sites that redirect mobile users to a malicious resource .


There the user is prompted to download and install a Trojan imitating an Adobe Flash Player update .


Svpeng is capable of doing lots of things .


It collects information about the smartphone ( IMEI , country , service provider , operating system language ) and sends it to the host via the HTTP POST request .


This appears to be necessary to determine the number of banks the victim may use .


Svpeng is only currently attacking clients of Russian banks .


Typically , however , cybercriminals first test-run a technology on the Russian sector of the Internet and then roll it out globally , attacking users in other countries .


It steals SMS messages and information about voice calls .


It helps the attacker find out which banks the owner of the smartphone calls – the Trojan receives a list of bank phone numbers from its C & C server .


It steals money from the victim ’ s bank account .


In Russia , some major banks offer their clients a special service that allows them to transfer money from their bank card to their mobile phone account .


Customers have to send a set text message from their phone to a specific bank number .


Svpeng sends the corresponding messages to the SMS services of two banks .


Svpeng does this to check if the cards from these banks are attached to the number of the infected phone and to find out the account balance .


If the phone is attached to a bank card , commands are sent from the C & C server with instructions to transfer money from the user ’ s bank account to his/her mobile account .


The cybercriminals then send this money to a digital wallet or to a premium number and cash it in .


It steals logins and passwords to online banking accounts by substituting he window displayed by the bank application .


Currently , this only affects Russian banks , but the technology behind Svpeng could easily be used to target other banking applications .


It steals bank card information ( the number , the expiry date , CVC2/CVV2 ) imitating the process of registering the bank card with Google Play .


If the user has launched Play Market , the Trojan intercepts the event and displays a window on top of the Google Play window , prompting the user to enter his/her bank card details in the fake window .


The data entered by the user is sent to the cybercriminals .


mobile_treats_2013_06s It extorts money from users by threatening to block the smartphone : it displays a message demanding $ 500 to unblock the device .


In actual fact , the Trojan does not block anything and the phone can be used without any problems .


It hides traces of its activity by masking the outgoing and incoming text messages and blocking calls and messages from numbers belonging to the bank .


The Trojan gets the list of bank phone numbers from its C & C server .


It protects itself from deletion by requesting Device Administrator rights during the installation .


As a result , the Trojan delete button in the list of applications becomes inactive , which may cause problems for inexperienced users .


It is impossible to deprive it of these rights without the use of specialized tools ( such as Kaspersky Internet Security for Android ) .


To protect itself from being removed , Svpeng uses a previously unknown vulnerability in Android .


It uses the same trick to prevent the smartphone from being returned to its factory settings .


The Trojan is distributed in Russia and CIS countries .


But , as we have already mentioned , the criminals could easily turn their attention to users in other countries .


Perkele and Wroba Foreign users have also been on the receiving end of several malicious innovations targeting bank accounts .


The Perkele Android Trojan not only attacks Russian users but also clients of several European banks .


It is of interest primarily because it operates in conjunction with various banking win32-Trojans .


Its main task is to bypass the two-factor authentication of the client in the online banking system .


Due to the specific nature of its activity , Perkele is distributed in a rather unusual way .


When a user enters an Internet banking site on a computer infected by banking malware ( ZeuS , Citadel ) , a request about the smartphone number and type of operating system is injected into the code of the authentication page .


This data is immediately sent to the cybercriminals and the computer displays the QR code containing a link to the alleged certificate of the online banking system .


After scanning the QR code and installing a component downloaded from the link , the user infects his smartphone with the Trojan program that boasts functionality that is of great interest to the attackers .


Perkele intercepts mTANs ( confirmation codes for banking operations ) sent by the bank via text message .


By using the login and password stolen from the browser , the Windows Trojan initiates a fake transaction while Perkele intercepts ( via the C & C server ) the mTAN sent by the bank to the user .


Money then disappears from the victim ’ s account and is cashed in without the owner ’ s knowledge .


The Korean malware Wroba , in addition to the traditional vector of infection via file-sharing services , spreads via alternative app stores .


Once it infects a device , Wroba behaves very aggressively .


It searches for mobile banking applications , removes them and uploads counterfeit versions .


From the outside , they are indistinguishable from the legitimate applications .


However , they possess no banking functions , and merely steal the logins and passwords entered by users .


ViperRAT : The Mobile APT Targeting The Israeli Defense Force That Should Be On Your Radar February 16 , 2017 ViperRAT is an active , advanced persistent threat ( APT ) that sophisticated threat actors are actively using to target and spy on the Israeli Defense Force.The threat actors behind the ViperRAT surveillanceware collect a significant amount of sensitive information off of the device , and seem most interested in exfiltrating images and audio content .


The attackers are also hijacking the device camera to take pictures .


Using data collected from the Lookout global sensor network , the Lookout research team was able to gain unique visibility into the ViperRAT malware , including 11 new , unreported applications .


We also discovered and analyzed live , misconfigured malicious command and control servers ( C2 ) , from which we were able to identify how the attacker gets new , infected apps to secretly install and the types of activities they are monitoring .


In addition , we uncovered the IMEIs of the targeted individuals ( IMEIs will not be shared publicly for the privacy and safety of the victims ) as well as the types of exfiltrated content .


In aggregate , the type of information stolen could let an attacker know where a person is , with whom they are associated ( including contacts ’ profile photos ) , the messages they are sending , the websites they visit and search history , screenshots that reveal data from other apps on the device , the conversations they have in the presence of the device , and a myriad of images including anything at which device ’ s camera is pointed .


Lookout has determined ViperRAT is a very sophisticated threat that adds to the mounting evidence that targeted mobile attacks against governments and business is a real problem .


Lookout researchers have been tracking this threat for the last month .


Given that this is an active threat , we ’ ve been working behind-the-scenes with our customers to ensure both personal and enterprise customers are protected from this threat and only decided to come forward with this information after the research team at Kaspersky released a report earlier today .


Additionally , we have determined that though original reports of this story attribute this surveillanceware tool to Hamas , this may not be the case , as we demonstrate below .


The increasing sophistication of surveillanceware The structure of the surveillanceware indicates it is very sophisticated .


Analysis indicates there are currently two distinct variants of ViperRAT .


The first variant is a “ first stage application , ” that performs basic profiling of a device , and under certain conditions attempts to download and install a much more comprehensive surveillanceware component , which is the second variant .


The first variant involves social engineering the target into downloading a trojanized app .


Previous reports alleged this surveillanceware tool was deployed using ‘ honey traps ’ where the actor behind it would reach out to targets via fake social media profiles of young women .


After building an initial rapport with targets , the actors behind these social media accounts would instruct victims to install an additional app for easier communication .


Specifically , Lookout determined these were trojanized versions of the apps SR Chat and YeeCall Pro .


We also uncovered ViperRAT in a billiards game , an Israeli Love Songs player , and a Move To iOS app .


The second stage The second stage apps contain the surveillanceware capabilities .


Lookout uncovered nine secondary payload applications : * These apps have not been previously reported and were discovered using data from the Lookout global sensor network , which collects app and device information from over 100 million sensors to provide researchers and customers with a holistic look at the mobile threat ecosystem today .


Naming additional payload applications as system updates is a clever technique used by malware authors to trick victims into believing a threat isn ’ t present on their device .


ViperRAT takes this one step further by using its dropper app to identify an appropriate second stage ‘ update ’ that may go unnoticed .


For example , if a victim has Viber on their device , it will choose to retrieve the Viber Update second stage .


If he doesn ’ t have Viber , the generically-named System Updates app gets downloaded and installed instead .


What was taken The actors behind ViperRAT seem to be particularly interested in image data .


We were able to identify that 8,929 files had been exfiltrated from compromised devices and that the overwhelming majority of these , 97 percent , were highly likely encrypted images taken using the device camera .


We also observed automatically generated files on the C2 , indicating the actor behind this campaign also issues commands to search for and exfiltrate PDF and Office documents .


This should be highly alarming to any government agency or enterprise .


We observed legitimate exfiltrated files of the following types of data : Contact information Compressed recorded audio in the Adaptive Multi-Rate ( amr ) file format Images captured from the device camera Images stored on both internal device and SDCard storage that are listed in the MediaStore Device geolocation information SMS content Chrome browser search history and bookmarks Call log information Cell tower information Device network metadata ; such as phone number , device software version , network country , network operator , SIM country , SIM operator , SIM serial , IMSI , voice mail number , phone


type , network type , data state , data activity , call state , SIM state , whether device is roaming , and if SMS is supported .


Standard browser search history Standard browser bookmarks Device handset metadata ; such as brand , display , hardware , manufacturer , product , serial , radio version , and SDK .


Command and control API calls ViperRAT samples are capable of communicating to C2 servers through an exposed API as well as websockets .


Below is a collection of API methods and a brief description around their purpose .


On attribution Media reporting on ViperRAT thus far attributes this surveillanceware tool to Hamas .


Israeli media published the first reports about the social networking and social engineering aspects of this campaign .


However it ’ s unclear whether organizations that later reported on ViperRAT performed their own independent research or simply based their content on the original Israeli report .


Hamas is not widely known for having a sophisticated mobile capability , which makes it unlikely they are directly responsible for ViperRAT .


ViperRAT has been operational for quite some time , with what appears to be a test application that surfaced in late 2015 .


Many of the default strings in this application are in Arabic , including the name .


It is unclear whether this means early samples were targeting Arabic speakers or if the developers behind it are fluent in Arabic .


This leads us to believe this is another actor .


What this means for you All Lookout customers are protected from this threat .


However , the existence of threats like ViperRAT and Pegasus , the most sophisticated piece of mobile surveillanceware we ’ ve seen to date , are evidence that attackers are targeting mobile devices .


Mobile devices are at the frontier of cyber espionage , and other criminal motives .


Enterprise and government employees all use these devices in their day-to-day work , which means IT and security leaders within these organizations must prioritize mobile in their security strategies .


Check Point researchers discovered another widespread malware campaign on Google Play , Google ’ s official app store .


The malware , dubbed “ Judy ” , is an auto-clicking adware which was found on 41 apps developed by a Korean company .


The malware uses infected devices to generate large amounts of fraudulent clicks on advertisements , generating revenues for the perpetrators behind it .


The malicious apps reached an astonishing spread between 4.5 million and 18.5 million downloads .


Some of the apps we discovered resided on Google Play for several years , but all were recently updated .


It is unclear how long the malicious code existed inside the apps , hence the actual spread of the malware remains unknown .


We also found several apps containing the malware , which were developed by other developers on Google Play .


The connection between the two campaigns remains unclear , and it is possible that one borrowed code from the other , knowingly or unknowingly .


The oldest app of the second campaign was last updated in April 2016 , meaning that the malicious code hid for a long time on the Play store undetected .


These apps also had a large amount of downloads between 4 and 18 million , meaning the total spread of the malware may have reached between 8.5 and 36.5 million users .


Similar to previous malware which infiltrated Google Play , such as FalseGuide and Skinner , Judy relies on the communication with its Command and Control server ( C & C ) for its operation .


After Check Point notified Google about this threat , the apps were swiftly removed from the Play store .


How Judy operates : To bypass Bouncer , Google Play ’ s protection , the hackers create a seemingly benign bridgehead app , meant to establish connection to the victim ’ s device , and insert it into the app store .


Once a user downloads a malicious app , it silently registers receivers which establish a connection with the C & C server .


The server replies with the actual malicious payload , which includes JavaScript code , a user-agent string and URLs controlled by the malware author .


The malware opens the URLs using the user agent that imitates a PC browser in a hidden webpage and receives a redirection to another website .


Once the targeted website is launched , the malware uses the JavaScript code to locate and click on banners from the Google ads infrastructure .


Upon clicking the ads , the malware author receives payment from the website developer , which pays for the illegitimate clicks and traffic .


The JavaScript code locates the targeted ads by searching for iframes which contain ads from Google ads infrastructure , as shown in the image below : The fraudulent clicks generate a large revenue for the perpetrators , especially since the malware reached a presumably wide spread .


Who is behind Judy ?


The malicious apps are all developed by a Korean company named Kiniwini , registered on Google Play as ENISTUDIO corp .


The company develops mobile apps for both Android and iOS platforms .


It is quite unusual to find an actual organization behind mobile malware , as most of them are developed by purely malicious actors .


It is important to note that the activity conducted by the malware is not borderline advertising , but definitely an illegitimate use of the users ’ mobile devices for generating fraudulent clicks , benefiting the attackers .


In addition to the clicking activity , Judy displays a large amount of advertisements , which in some cases leave users with no option but clicking on the ad itself .


Although most apps have positive ratings , some of the users have noticed and reported Judy ’ s suspicious activities , as seen in the images below : As seen in previous malware , such as DressCode , a high reputation does not necessarily indicate that the app is safe for use .


Hackers can hide their apps ’ real intentions or even manipulate users into leaving positive ratings , in some cases unknowingly .


Users can not rely on the official app stores for their safety , and should implement advanced security protections capable of detecting and blocking zero-day mobile malware .


PHA Family Highlights : Bread ( and Friends ) January 9 , 2020 In this edition of our PHA Family Highlights series we introduce Bread , a large-scale billing fraud family .


We first started tracking Bread ( also known as Joker ) in early 2017 , identifying apps designed solely for SMS fraud .


As the Play Store has introduced new policies and Google Play Protect has scaled defenses , Bread apps were forced to continually iterate to search for gaps .


They have at some point used just about every cloaking and obfuscation technique under the sun in an attempt to go undetected .


Many of these samples appear to be designed specifically to attempt to slip into the Play Store undetected and are not seen elsewhere .


In this post , we show how Google Play Protect has defended against a well organized , persistent attacker and share examples of their techniques .


TL ; DR Google Play Protect detected and removed 1.7k unique Bread apps from the Play Store before ever being downloaded by users Bread apps originally performed SMS fraud , but have largely abandoned this for WAP billing following the introduction of new Play policies restricting use of the SEND_SMS permission and increased coverage by Google Play Protect More information on stats and relative impact is available in the Android Security 2018 Year in Review report BILLING FRAUD Bread apps typically fall into two categories : SMS fraud ( older versions ) and toll fraud ( newer versions ) .


Both of these types of fraud take advantage of mobile billing techniques involving the user ’ s carrier .


SMS Billing Carriers may partner with vendors to allow users to pay for services by SMS .


The user simply needs to text a prescribed keyword to a prescribed number ( shortcode ) .


A charge is then added to the user ’ s bill with their mobile service provider .


Toll Billing Carriers may also provide payment endpoints over a web page .


The user visits the URL to complete the payment and enters their phone number .


Verification that the request is coming from the user ’ s device is completed using two possible methods : The user connects to the site over mobile data , not WiFi ( so the service provider directly handles the connection and can validate the phone number ) ; or The user must retrieve a code sent to them via SMS and enter it into the web page ( thereby proving access to the provided phone number ) .


Fraud Both of the billing methods detailed above provide device verification , but not user verification .


The carrier can determine that the request originates from the user ’ s device , but does not require any interaction from the user that can not be automated .


Malware authors use injected clicks , custom HTML parsers and SMS receivers to automate the billing process without requiring any interaction from the user .


STRING & DATA OBFUSCATION Bread apps have used many innovative and classic techniques to hide strings from analysis engines .


Here are some highlights .


Standard Encryption Frequently , Bread apps take advantage of standard crypto libraries in ` java.util.crypto ` .


We have discovered apps using AES , Blowfish , and DES as well as combinations of these to encrypt their strings .


Custom Encryption Other variants have used custom-implemented encryption algorithms .


Some common techniques include : basic XOR encryption , nested XOR and custom key-derivation methods .


Some variants have gone so far as to use a different key for the strings of each class .


Split Strings Encrypted strings can be a signal that the code is trying to hide something .


Bread has used a few tricks to keep strings in plaintext while preventing basic string matching .


Going one step further , these substrings are sometimes scattered throughout the code , retrieved from static variables and method calls .


Various versions may also change the index of the split ( e.g .


“ .clic ” and “ k ( ) ; ” ) .


Delimiters Another technique to obfuscate unencrypted strings uses repeated delimiters .


A short , constant string of characters is inserted at strategic points to break up keywords : At runtime , the delimiter is removed before using the string : API OBFUSCATION SMS and toll fraud generally requires a few basic behaviors ( for example , disabling WiFi or accessing SMS ) , which are accessible by a handful of APIs .


Given that there are a limited number of behaviors required to identify billing fraud , Bread apps have had to try a wide variety of techniques to mask usage of these APIs .


Reflection Most methods for hiding API usage tend to use Java reflection in some way .


In some samples , Bread has simply directly called the Reflect API on strings decrypted at runtime .


JNI Bread has also tested our ability to analyze native code .


In one sample , no SMS-related code appears in the DEX file , but there is a native method registered .


Two strings are passed into the call , the shortcode and keyword used for SMS billing ( getter methods renamed here for clarity ) .


In the native library , it stores the strings to access the SMS API .


The nativesend method uses the Java Native Interface ( JNI ) to fetch and call the Android SMS API .


The following is a screenshot from IDA with comments showing the strings and JNI functions .


WebView JavaScript Interface Continuing on the theme of cross-language bridges , Bread has also tried out some obfuscation methods utilizing JavaScript in WebViews .


The following method is declared in the DEX .


Without context , this method does not reveal much about its intended behavior , and there are no calls made to it anywhere in the DEX .


However , the app does create a WebView and registers a JavaScript interface to this class .


This gives JavaScript run in the WebView access to this method .


The app loads a URL pointing to a Bread-controlled server .


The response contains some basic HTML and JavaScript .


In green , we can see the references to the SMS API .


In red , we see those values being passed into the suspicious Java method through the registered interface .


Now , using these strings method1 can use reflection to call sendTextMessage and process the payment .


PACKING In addition to implementing custom obfuscation techniques , apps have used several commercially available packers including : Qihoo360 , AliProtect and SecShell .


More recently , we have seen Bread-related apps trying to hide malicious code in a native library shipped with the APK .


Earlier this year , we discovered apps hiding a JAR in the data section of an ELF file which it then dynamically loads using DexClassLoader .


The figure below shows a fragment of encrypted JAR stored in .rodata section of a shared object shipped with the APK as well as the XOR key used for decryption .


After we blocked those samples , they moved a significant portion of malicious functionality into the native library , which resulted in a rather peculiar back and forth between Dalvik and native code : COMMAND & CONTROL Dynamic Shortcodes & Content Early versions of Bread utilized a basic command and control infrastructure to dynamically deliver content and retrieve billing details .


In the example server response below , the green fields show text to be shown to the user .


The red fields are used as the shortcode and keyword for SMS billing .


State Machines Since various carriers implement the billing process differently , Bread has developed several variants containing generalized state machines implementing all possible steps .


At runtime , the apps can check which carrier the device is connected to and fetch a configuration object from the command and control server .


The configuration contains a list of steps to execute with URLs and JavaScript .


The steps implemented include : Load a URL in a WebView Run JavaScript in WebView Toggle WiFi state Toggle mobile data state Read/modify SMS inbox Solve captchas Captchas One of the more interesting states implements the ability to solve basic captchas ( obscured letters and numbers ) .


First , the app creates a JavaScript function to call a Java method , getImageBase64 , exposed to WebView using addJavascriptInterface .


The value used to replace GET_IMG_OBJECT comes from the JSON configuration .


The app then uses JavaScript injection to create a new script in the carrier ’ s web page to run the new function .


The base64-encoded image is then uploaded to an image recognition service .


If the text is retrieved successfully , the app uses JavaScript injection again to submit the HTML form with the captcha answer .


CLOAKING Client-side Carrier Checks In our basic command & control example above , we didn ’ t address the ( incorrectly labeled ) “ imei ” field .


This contains the Mobile Country Code ( MCC ) and Mobile Network Code ( MNC ) values that the billing process will work for .


In this example , the server response contains several values for Thai carriers .


The app checks if the device ’ s network matches one of those provided by the server .


If it does , it will commence with the billing process .


If the value does not match , the app skips the “ disclosure ” page and billing process and brings the user straight to the app content .


In some versions , the server would only return valid responses several days after the apps were submitted .


Server-side Carrier Checks In the JavaScript bridge API obfuscation example covered above , the server supplied the app with the necessary strings to complete the billing process .


However , analysts may not always see the indicators of compromise in the server ’ s response .


In this example , the requests to the server take the following form : Here , the “ operator ” query parameter is the Mobile Country Code and Mobile Network Code .


The server can use this information to determine if the user ’ s carrier is one of Bread ’ s targets .


If not , the response is scrubbed of the strings used to complete the billing fraud .


MISLEADING USERS Bread apps sometimes display a pop-up to the user that implies some form of compliance or disclosure , showing terms and conditions or a confirm button .


However , the actual text would often only display a basic welcome message .


Other versions included all the pieces needed for a valid disclosure message .


However , there are still two issues here : The numbers to contact for cancelling the subscription are not real The billing process commences even if you don ’ t hit the “ Confirm ” button Even if the disclosure here displayed accurate information , the user would often find that the advertised functionality of the app did not match the actual content .


Bread apps frequently contain no functionality beyond the billing process or simply clone content from other popular apps .


VERSIONING Bread has also leveraged an abuse tactic unique to app stores : versioning .


Some apps have started with clean versions , in an attempt to grow user bases and build the developer accounts ’ reputations .


Only later is the malicious code introduced , through an update .


Interestingly , early “ clean ” versions contain varying levels of signals that the updates will include malicious code later .


Some are first uploaded with all the necessary code except the one line that actually initializes the billing process .


Others may have the necessary permissions , but are missing the classes containing the fraud code .


And others have all malicious content removed , except for log comments referencing the payment process .


All of these methods attempt to space out the introduction of possible signals in various stages , testing for gaps in the publication process .


However , GPP does not treat new apps and updates any differently from an analysis perspective .


FAKE REVIEWS When early versions of apps are first published , many five star reviews appear with comments like : “ So .. good .. ” “ very beautiful ” Later , 1 star reviews from real users start appearing with comments like : “ Deception ” “ The app is not honest … ” SUMMARY Sheer volume appears to be the preferred approach for Bread developers .


At different times , we have seen three or more active variants using different approaches or targeting different carriers .


Within each variant , the malicious code present in each sample may look nearly identical with only one evasion technique changed .


Sample 1 may use AES-encrypted strings with reflection , while Sample 2 ( submitted on the same day ) will use the same code but with plaintext strings .


At peak times of activity , we have seen up to 23 different apps from this family submitted to Play in one day .


At other times , Bread appears to abandon hope of making a variant successful and we see a gap of a week or longer before the next variant .


This family showcases the amount of resources that malware authors now have to expend .


Google Play Protect is constantly updating detection engines and warning users of malicious apps installed on their device .


SELECTED SAMPLES Package Name SHA-256 Digest com.rabbit.artcamera 18c277c7953983f45f2fe6ab4c7d872b2794c256604e43500045cb2b2084103f org.horoscope.astrology.predict 6f1a1dbeb5b28c80ddc51b77a83c7a27b045309c4f1bff48aaff7d79dfd4eb26 com.theforest.rotatemarswallpaper 4e78a26832a0d471922eb61231bc498463337fed8874db5f70b17dd06dcb9f09


com.jspany.temp 0ce78efa764ce1e7fb92c4de351ec1113f3e2ca4b2932feef46d7d62d6ae87f5 com.hua.ru.quan 780936deb27be5dceea20a5489014236796a74cc967a12e36cb56d9b8df9bc86 com.rongnea.udonood 8b2271938c524dd1064e74717b82e48b778e49e26b5ac2dae8856555b5489131


com.mbv.a.wp 01611e16f573da2c9dbc7acdd445d84bae71fecf2927753e341d8a5652b89a68 com.pho.nec.sg b4822eeb71c83e4aab5ddfecfb58459e5c5e10d382a2364da1c42621f58e119b Exobot ( Marcher ) - Android banking Trojan on the rise February 2017 Introduction The past months many different banking Trojans for


the Android platform have received media attention .


One of these , called Marcher ( aka Exobot ) , seems to be especially active with different samples appearing on a daily basis .


This malware variant also appears to be technically superior to many other banking Trojans being able to use its overlay attack even on Android 6 , which has technical improvements compared to the previous Android versions to prevent such attacks .


The main infection vector is a phishing attack using SMS/MMS .


The social engineering message includes a link that leads to a fake version of a popular app , using names like Runtastic , WhatsApp or Netflix .


On installation , the app requests the user to provide SMS storage access and high Android privileges such as Device Admin .


Other infection vectors include pornographic websites serving apps called Adobe Flash or YouPorn .


The Marcher banking malware uses two main attack vectors .


The first attack vector is to compromise the out of band authentication for online banks that rely on SMS using SMS forwarding .


The second attack vector , the overlay attack , shows a customized phishing window whenever a targeted application is started on the device .


The overlay window is often indistinguishable from the expected screen ( such as a login screen for a banking app ) and is used to steal the victim ’ s banking credentials .


The target list and bank specific fake login pages can be dynamically updated via their C2 panel ( dashboard back-end ) which significantly increases the adaptability and scalability of this attack .


In addition , this type of Android banking malware does not require the device to be rooted or the app to have any specific Android permission ( besides android.permission.INTERNET to retrieve the overlay contents and send its captured data ) .


The many changes we see in the way the attacks are performed show that attackers are heavily experimenting to find the best way of infecting a mobile device and abusing existing functionality to perform successful phishing attacks .


The next stage in device infection could be the use of exploit kits and malvertising , which would be quite effective due the many Android vulnerabilities and consumers with unpatched devices .


In addition future Trojans could leverage root exploits to make them almost impossible to remove and give malicious actors the ability to hook generic low level API ’ s that are used by all ( banking ) applications , just like the attack vector as has been used on the desktop platform for years .


Technical Analysis Permissions Marcher ’ s APK size is fairly small ( only 683KB for sample eb8f02fc30ec49e4af1560e54b53d1a7 ) , much smaller than most legitimate apps and other popular mobile malware samples .


This sample only includes Dalvik bytecode and resources without any native libraries .


The package name ( vyn.hhsdzgvoexobmkygffzwuewrbikzud ) and its many activities and services have randomized names , probably to make it a bit more difficult to detect the package using blacklisting .


The set of permissions required by Marcher according to the manifest is as follows : ∗ android.permission.CHANGE_NETWORK_STATE ( change network connectivity state ) ∗ android.permission.SEND_SMS ( send SMS messages ) ∗ android.permission.USES_POLICY_FORCE_LOCK ( lock the device ) ∗ android.permission.RECEIVE_BOOT_COMPLETED ( start malware when device boots ) ∗ android.permission.INTERNET ( communicate with the internet ) ∗ android.permission.VIBRATE


( control the vibrator ) ∗ android.permission.ACCESS_WIFI_STATE ( view information about the status of Wi-Fi ) ∗ android.permission.WRITE_SMS ( edit/delete SMS ) ∗ android.permission.ACCESS_NETWORK_STATE ( view the status of all networks ) ∗ android.permission.WAKE_LOCK ( prevent the phone from going to sleep ) ∗ android.permission.GET_TASKS ( retrieve running applications ) ∗ android.permission.CALL_PHONE ( call phone numbers )


∗ android.permission.WRITE_SETTINGS ( read/write global system settings ) ∗ android.permission.RECEIVE_SMS ( intercept SMS messages ) ∗ android.permission.READ_PHONE_STATE ( read phone details of the device such as phone number and serial number ) ∗ android.permission.CHANGE_WIFI_STATE ( connect to and disconnect from Wi-Fi networks and make changes to configured networks ) ∗ android.permission.READ_CONTACTS ( read all contact data ) * android.permission.READ_SMS


( read SMS messages ) Obviously a fairly significant list of permissions of which many are suspicious , especially when combined .


Runtastic sample permission prompt Runtastic sample permission prompt Checking foreground app Marcher is one of the few Android banking Trojans to use the AndroidProcesses library , which enables the application to obtain the name of the Android package that is currently running in the foreground .


This library is used because it uses the only ( publicly known ) way to retrieve this information on Android 6 ( using the process OOM score read from the /proc directory ) .


When the current app on the foreground matches with an app targeted by the malware , the Trojan will show the corresponding phishing overlay , making the user think it is the app that was just started .


Dynamic overlays When victims open up a targeted app , Marcher smoothly displays an overlay , a customized WebView , looks in its application preferences ( main_prefs.xml ) and decides which specified URL is needed for the targeted app .


The complete list of apps can be seen below .


The phishing pages shown in the overlay use Ajax calls to communicate with a PHP back-end which stores all user input .


The C2 backend url looks like this : https : //evilhost/c2folder/njs2/ ?


fields [ ] .


There is no way to access the original app again even if victims terminate the overlay process and reopen app , until credit card ( name , number , expiry date , security code ) and/or bank information ( PIN , VBV passcode , date of birth , etc .


) are filled in and verified .


The information is then stored in local app database as well as sent to the backend .


Agent Smith : A New Species of Mobile Malware July 10 , 2019 Check Point Researchers recently discovered a new variant of mobile malware that quietly infected around 25 million devices , while the user remains completely unaware .


Disguised as Google related app , the core part of malware exploits various known Android vulnerabilities and automatically replaces installed apps on the device with malicious versions without the user ’ s interaction .


This unique on-device , just-in-time ( JIT ) approach inspired researchers to dub this malware as “ Agent Smith ” .


“ Agent Smith ” currently uses its broad access to the device ’ s resources to show fraudulent ads for financial gain .


This activity resembles previous campaigns such as Gooligan , HummingBad and CopyCat .


The primary targets , so far , are based in India though other Asian countries such as Pakistan and Bangladesh are also affected .


In a much-improved Android security environment , the actors behind Agent Smith seem to have moved into the more complex world of constantly searching for new loopholes , such as Janus , Bundle and Man-in-the-Disk , to achieve a 3-stage infection chain , in order to build a botnet of controlled devices to earn profit for the perpetrator .


“ Agent Smith ” is possibly the first campaign seen that ingrates and weaponized all these loopholes and are described in detail below .


In this case , “ Agent Smith ” is being used to for financial gain through the use of malicious advertisements .


However , it could easily be used for far more intrusive and harmful purposes such as banking credential theft .


Indeed , due to its ability to hide it ’ s icon from the launcher and impersonates any popular existing apps on a device , there are endless possibilities for this sort of malware to harm a user ’ s device .


Check Point Research has submitted data to Google and law enforcement units to facilitate further investigation .


As a result , information related to the malicious actor is tentatively redacted in this publication .


Check Point has worked closely with Google and at the time of publishing , no malicious apps remain on the Play Store .


Encounter In early 2019 , the Check Point Research team observed a surge of Android malware attack attempts against users in India which had strong characteristics of Janus vulnerability abuse ; All samples our team collected during preliminary investigation had the ability to hide their app icons and claim to be Google related updaters or vending modules ( a key component of Google Play framework ) .


Upon further analysis it became clear this application was as malicious as they come and initially resembled the CopyCat malware , discovered by Check Point Research back in April 2016 .


As the research progressed , it started to reveal unique characteristics which made us believe we were looking at an all-new malware campaign found in the wild .


After a series of technical analysis ( which is covered in detail below ) and heuristic threat hunting , we discovered that a complete “ Agent Smith ” infection has three main phases : A dropper app lures victim to install itself voluntarily .


The initial dropper has a weaponized Feng Shui Bundle as encrypted asset files .


Dropper variants are usually barely functioning photo utility , games , or sex related apps .


The dropper automatically decrypts and installs its core malware APK which later conducts malicious patching and app updates .


The core malware is usually disguised as Google Updater , Google Update for U or “ com.google.vending ” .


The core malware ’ s icon is hidden .


The core malware extracts the device ’ s installed app list .


If it finds apps on its prey list ( hard-coded or sent from C & C server ) , it will extract the base APK of the target innocent app on the device , patch the APK with malicious ads modules , install the APK back and replace the original one as if it is an update .


“ Agent Smith ” repacks its prey apps at smali/baksmali code level .


During the final update installation process , it relies on the Janus vulnerability to bypass Android ’ s APK integrity checks .


Upon kill chain completion , “ Agent Smith ” will then hijack compromised user apps to show ads .


In certain situations , variants intercept compromised apps ’ original legitimate ads display events and report back to the intended ad-exchange with the “ Agent Smith ” campaign hacker ’ s ad IDs .


Our intelligence shows “ Agent Smith ” droppers proliferate through third-party app store “ 9Apps ” , a UC team backed store , targeted mostly at Indian ( Hindi ) , Arabic , and Indonesian users .


“ Agent Smith ” itself , though , seems to target mainly India users .


Unlike previously discovered non Google Play centric campaigns whose victims almost exclusively come from less developed countries and regions , “ Agent Smith ” successfully penetrated into noticeable number of devices in developed countries such as Saudi Arabia , UK and US .


Technical Analysis “ Agent Smith ” has a modular structure and consists of the following modules : Loader Core Boot Patch AdSDK Updater As stated above , the first step of this infection chain is the dropper .


The dropper is a repacked legitimate application which contains an additional piece of code – “ loader ” .


The loader has a very simple purpose , extract and run the “ core ” module of “ Agent Smith ” .


The “ core ” module communicates with the C & C server , receiving the predetermined list of popular apps to scan the device for .


If any application from that list was found , it utilizes the Janus vulnerability to inject the “ boot ” module into the repacked application .


After the next run of the infected application , the “ boot ” module will run the “ patch ” module , which hooks the methods from known ad SDKs to its own implementation .


Figure 1 : ‘ Agent Smith ’ s modular structure Technical Analysis – Loader Module The “ loader ” module , as stated above , extracts and runs the “ core ” module .


While the “ core ” module resides inside the APK file , it is encrypted and disguised as a JPG file – the first two bytes are actually the magic header of JPG files , while the rest of the data is encoded with an XOR cipher .


Figure 2 : “ Agent Smith ’ s jpg file structure After the extraction , the “ loader ” module adds the code to the application while using the legitimate mechanism by Android to handle large DEX files .


Figure 3 : Loading core malicious code into the benign application Once the “ core ” module is extracted and loaded , the “ loader ” uses the reflection technique to initialize and start the “ core ” module .


Figure 4 : Loader calls initialization method Technical Analysis – Core Module With the main purpose of spreading the infection , “ Agent Smith ” implements in the “ core ” module : A series of ‘ Bundle ’ vulnerabilities , which is used to install applications without the victim ’ s awareness .


The Janus vulnerability , which allows the actor to replace any application with an infected version .


The “ core ” module contacts the C & C server , trying to get a fresh list of applications to search for , or if that fails , use a default app list : whatsapp lenovo.anyshare.gps mxtech.videoplayer.ad jio.jioplay.tv jio.media.jiobeats jiochat.jiochatapp jio.join good.gamecollection opera.mini.native startv.hotstar meitu.beautyplusme domobile.applock touchtype.swiftkey flipkart.android cn.xender


eterno truecaller For each application on the list , the “ core ” module checks for a matching version and MD5 hash of the installed application , and also checks for the application running in the user-space .


If all conditions are met , “ Agent Smith ” tries to infect the application .


The “ core ” module will use one of two methods to infect the application – Decompile and Binary .


The decompile method is based on the fact that Android applications are Java-based , meaning it is possible to recompile it .


Therefore , “ Agent Smith ” decompiles both the original application and the malicious payload and fuses them together .


Figure 5 : core module mixes malicious payload with the original application While decompiling the original app , “ Agent Smith ” has the opportunity to modify the methods inside , replace some of the methods in the original application that handles advertisement with its own code and focus on methods communicating with ‘ AdMob ’ , ‘ Facebook ’ , ‘ MoPub ’ and ‘ Unity Ads ’ .


Figure 6 : Targeted ad network Figure 7 : Injection example After all of the required changes , “ Agent Smith ” compiles the application and builds a DEX file containing both the original code of the original application and the malicious payload .


In some cases , the decompilation process will fail , and “ Agent Smith ” will try another method for infecting the original application – A binary patch , which simply provides a binary file of the “ boot ” module of “ Agent Smith ” .


Once the payload is prepared , “ Agent Smith ” uses it to build another APK file , exploiting the Janus vulnerability : Figure 8 : The new infected APK file structure Solely injecting the code of the loader is not enough .


As “ Agent Smith ” uses a modular approach , and as stated earlier , the original loader extracts everything from the assets , the usage of the Janus vulnerability can only change the code of the original application , not the resources .


This means that the only thing possible in this case is to replace its DEX file .


To overcome this issue , “ Agent Smith ” found another solution .


Seeing as the system loader of the DEX files ( ART ) fully ignores everything that goes after the data section , the patcher writes all of its resources right there .


This action changes the original file size of the DEX file , which makes the malicious resources a part of the DEX file , a section that is ignored by the signature validation process .


Figure 9 : Malware secretly adds malicious resources to the DEX file Now , after the alteration of the original application , Android ’ s package manager will think that this is an update for the application signed by the same certificate , but in reality , it will execute the malicious DEX file .


Even now , this is still not enough .


“ Agent Smith ” needs to be updated/installed without the user ’ s consent .


To achieve this , “ Agent Smith ” utilizes a series of 1-day vulnerabilities , which allows any application to run an activity inside a system application , even if this activity is not exported .


The malicious application sends a request to choose a network account , a specific account that can only be processed by authentication services exported by the malicious application .


The system service ‘ AccountManagerService ’ looks for the application that can process this request .


While doing so , it will reach a service exported by “ Agent Smith ” , and sends out an authentication request that would lead to a call to the ‘ addAccount ’ method .


Then , a request is formed in such a way that an activity that installs the application is called , bypassing all security checks .


Figure 10 : The algorithm of the malicious update , while “ Agent Smith ” updates application If all that has failed , “ Agent Smith ” turns to Man-in-the-Disk vulnerability for ‘ SHAREit ’ or ‘ Xender ’ applications .


This is a very simple process , which is replacing their update file on SD card with its own malicious payload .


Figure 11 : ‘ Agent Smith ’ uses man-in-disk to install the malicious update Technical Analysis – Boot Module The “ boot ” module is basically another “ loader ” module , but this time it ’ s executed in the infected application .


The purpose of this module is to extract and execute a malicious payload – the “ patch ” module .


The infected application contains its payload inside the DEX file .


All that is needed is to get the original size of the DEX file and read everything that comes after this offset .


Figure 12 : Boot module After the patch module is extracted , the “ boot ” module executes it , using the same method described in the “ loader ” module .


The “ boot ” module has placeholder classes for the entry points of the infected applications .


This allows the “ boot ” module to execute the payloads when the infected application is started .


Figure 13 : placeholder classes in Boot module Technical Analysis – Patch Module When “ Agent Smith ” has reached its goal – a malicious payload running inside the original application , with hooks on various methods – at this point , everything lies with maintaining the required code in case of an update for the original application .


While investing a lot of resources in the development of this malware , the actor behind “ Agent Smith ” does not want a real update to remove all of the changes made , so here is where the “ patch ” module comes in to play With the sole purpose of disabling automatic updates for the infected application , this module observes the update directory for the original application and removes the file once it appears .


Another trick in “ Agent Smith ’ s arsenal is to change the settings of the update timeout , making the original application wait endlessly for the update check .


Figure 14 : disabling infected apps auto-update Figure 15 : changing the settings of the update timeout The Ad Displaying Payload Following all of the above , now is the time to take a look into the actual payload that displays ads to the victim .


In the injected payload , the module implements the method ‘ callActivityOnCreate ’ .


At any time an infected application will create an activity , this method will be called , and call ‘ requestAd ’ from “ Agent Smith ’ s code .


“ Agent Smith ” will replace the original application ’ s activities with an in-house SDK ’ s activity , which will show the banner received from the server .


In the case of the infected application not specified in the code , “ Agent Smith ” will simply show ads on the activity being loaded .


Figure 16 : integrating an in-house ad SDK Figure 17 : replacing original app activities with the malicious ad SDK activity Figure 18 : the malware showing ads on any activity being loaded Connecting the Dots As our malware sample analysis took the team closer to reveal the “ Agent Smith ” campaign in its entirety and it is here that the C & C server investigation enters the center stage .


We started with most frequently used C & C domains “ a * * * d.com ” , “ a * * * d.net ” , and “ a * * * d.org ” .


Among multiple sub-domains , “ ad.a * * * d.org ” and “ gd.a * * * d.org ” both historically resolved to the same suspicious IP address .


The reverse DNS history of this IP brought “ ads.i * * * e.com ” into our attention .


An extended malware hunting process returned to us a large set of “ Agent Smith ” dropper variants which helped us further deduce a relation among multiple C & C server infrastructures .


In a different period of the “ Agent Smith ” campaign , droppers and core modules used various combinations of the “ a * * * d ” and “ i * * * e ” domains for malicious operations such as prey list query , patch request and ads request .


With a bit of luck , we managed to find logs in which the evidence showed “ Agent Smith ’ s C & C front end routinely distributes a workload between “ w.h * * * g.com ” and “ tt.a * * * d.net ” .


An in-depth understanding of the “ Agent Smith ’ s campaign C & C infrastructure enabled us to reach the conclusion that the owner of “ i * * * e.com ” , “ h * * * g.com ” is the group of hackers behind “ Agent Smith ” .


Figure 19 : C & C infrastructure diagram The Infection Landscape “ Agent Smith ” droppers show a very greedy infection tactic .


It ’ s not enough for this malware family to swap just one innocent application with an infected double .


It does so for each and every app on the device as long as the package names are on its prey list .


Over time , this campaign will also infect the same device , repeatedly , with the latest malicious patches .


This lead us to estimate there to be over 2.8 billion infections in total , on around 25 Million unique devices , meaning that on average , each victim would have suffered roughly 112 swaps of innocent applications .


As an initial attack vector , “ Agent Smith ” abuses the 9Apps market – with over 360 different dropper variants .


To maximize profit , variants with “ MinSDK ” or “ OTA ” SDK are present to further infect victims with other adware families .


The majority of droppers in 9Apps are games , while the rest fall into categories of adult entertainment , media player , photo utilities , and system utilities .


Figure 20 : dropper app category distribution Among the vast number of variants , the top 5 most infectious droppers alone have been downloaded more than 7.8 million times of the infection operations against innocent applications : Figure 21 : Top 5 most infectious droppers The “ Agent Smith ” campaign is primarily targeted at Indian users , who represent 59 % of the impacted population .


Unlike previously seen non-GP ( Google Play ) centric malware campaigns , “ Agent Smith ” has a significant impact upon not only developing countries but also some developed countries where GP is readily available .


For example , the US ( with around 303k infections ) , Saudi Arabia ( 245k ) , Australia ( 141k ) and the UK ( 137k ) .


Figure 22 : world infection heat map Considering that India is by far the most infected county by “ Agent Smith ” , overall compromised device brand distribution is heavily influenced by brand popularity among Indian Android users : Figure 23 : infected brand distribution While most infections occurred on devices running Android 5 and 6 , we also see a considerable number of successful attacks against newer Android versions .


It is a worrying observation .


AOSP patched the Janus vulnerability since version 7 by introducing APK Signature Scheme V2 .


However , in order to block Janus abuse , app developers need to sign their apps with the new scheme so that Android framework security component could conduct integrity checks with enhanced features .


Figure 25 : infected Android version distribution To further analyze “ Agent Smith ” ’ s infection landscape , we dived into the top 10 infected countries : Country Total Devices Total Infection Event Count Avg .


App Swap Per Device Avg .


Droppers Per Device Avg .


Months Device Remained Infected India 15,230,123 2,017,873,249 2.6 1.7 2.1 Bangladesh 2,539,913 208,026,886 2.4 1.5 2.2 Pakistan 1,686,216 94,296,907 2.4 1.6 2 Indonesia 572,025 67,685,983 2 1.5 2.2 Nepal 469,274 44,961,341 2.4 1.6 2.4 US 302,852 19,327,093 1.7 1.4 1.8 Nigeria 287,167 21,278,498 2.4 1.3 2.3 Hungary 282,826 7,856,064 1.7 1.3 1.7 Saudi Arabia 245,698 18,616,259 2.3


1.6 1.9 Myanmar 234,338 9,729,572 1.5 1.4 1.9 “ Agent Smith ” Timeline Early signs of activity from the actor behind “ Agent Smith ” can be traced back to January 2016 .


We classify this 40-month period into three main stages .


January 2016 – May 2018 : In this stage , “ Agent Smith ” hackers started to try out 9Apps as a distribution channel for their adware .


During this period , malware samples display some typical adware characteristics such as unnecessary permission requirements and pop-up windows .


During this time , “ Agent Smith ” hackers eventually built up a vast number of app presence on 9Apps , which later would serve as publication channels for evolved droppers .


However , samples don ’ t have key capabilities to infect innocent apps on victim devices yet .


May 2018 to April 2019 : This is the actual mature stage of “ Agent Smith ” campaign .


From early 2018 prior to May , “ Agent Smith ” hackers started to experiment with Bundle Feng Shui , the key tool which gives “ Agent Smith ” malware family capabilities to infect innocent apps on the device .


A series of pilot runs were executed .


After some major upgrade , by mid-June , the “ Agent Smith ” campaign reached its peak .


Its dropper family finished integration with Bundle Feng Shui and campaign C & C infrastructure was shifted to AWS cloud .


The Campaign achieved exponential growth from June to December 2018 with the infection number staying stable into early 2019 .


Post-April 2019 : Starting from early 2019 , the new infection rate of “ Agent Smith ” dropped significantly .


From early April , hackers started to build a new major update to the “ Agent Smith ” campaign under the name “ leechsdk ” .


Figure 26 : “ Agent Smith ” Campaign timeline Greater “ Agent Smith ” Campaign Discovery Orchestrating a successful 9Apps centric malware campaign , the actor behind “ Agent Smith ” established solid strategies in malware proliferation and payload delivery .


The actor also built solid backend infrastructures which can handle high volume concurrent requests .


During our extended threat hunting , we uncovered 11 apps on the Google Play store that contain a malicious yet dormant SDK related to “ Agent Smith ” actor .


This discovery indicates the actor ’ s ambition in expanding operations into Google Play store with previous success experience from the main “ Agent Smith ” campaign .


Instead of embedding core malware payload in droppers , the actor switches to a more low-key SDK approach .


In the dangerous module lies a kill switch logic which looks for the keyword “ infect ” .


Once the keyword is present , the SDK will switch from innocent ads server to malicious payload delivery ones .


Hence , we name this new spin-off campaign as Jaguar Kill Switch .


The below code snippet is currently isolated and dormant .


In the future , it will be invoked by malicious SDK during banner ads display .


Figure 26 : the kill switch code snippet Evidence implies that the “ Agent Smith ” actor is currently laying the groundwork , increasing its Google Play penetration rate and waiting for the right timing to kick off attacks .


By the time of this publication , two Jaguar Kill Switch infected app has reached 10 million downloads while others are still in their early stages .


Check Point Research reported these dangerous apps to Google upon discovery .


Currently , all bespoke apps have been taken down from the Google Play store .


Figure 28 : Jaguar Kill Switch infected GP apps Peek Into the Actor Based on all of the above , we connected “ Agent Smith ” campaign to a Chinese internet company located in Guangzhou whose front end legitimate business is to help Chinese Android developers publish and promote their apps on overseas platforms .


Various recruitment posts on Chinese job sites and Chinese National Enterprise Credit Information Public System ( NECIPS ) data led us one step further , linking the actor to its legal entity name .


Interestingly , we uncovered several expired job posting of Android reverse engineer from the actor ’ s front business published in 2018 and 2019 .


It seems that the people who filled these roles are key to “ Agent Smith ’ s success , yet not quite necessary for actor ’ s legitimate side of business .


With a better understanding of the “ Agent Smith ” actor than we had in the initial phase of campaign hunting , we examined the list of target innocent apps once again and discovered the actor ’ s unusual practices in choosing targets .


It seems , “ Agent Smith ” prey list does not only have popular yet Janus vulnerable apps to ensure high proliferation , but also contain competitor apps of actor ’ s legitimate business arm to suppress competition .


Conclusion Although the actor behind “ Agent Smith ” decided to make their illegally acquired profit by exploiting the use of ads , another actor could easily take a more intrusive and harmful route .


With the ability to hide its icon from the launcher and hijack popular existing apps on a device , there are endless possibilities to harm a user ’ s digital even physical security .


Today this malware shows unwanted ads , tomorrow it could steal sensitive information ; from private messages to banking credentials and much more .


The “ Agent Smith ” campaign serves as a sharp reminder that effort from system developers alone is not enough to build a secure Android eco-system .


It requires attention and action from system developers , device manufacturers , app developers , and users , so that vulnerability fixes are patched , distributed , adopted and installed in time .


It is also another example for why organizations and consumers alike should have an advanced mobile threat prevention solution installed on the device to protect themselves against the possibility of unknowingly installing malicious apps , even from trusted app stores .


Dvmap : the first Android malware with code injection 08 JUN 2017 In April 2017 we started observing new rooting malware being distributed through the Google Play Store .


Unlike other rooting malware , this Trojan not only installs its modules into the system , it also injects malicious code into the system runtime libraries .


Kaspersky Lab products detect it as Trojan.AndroidOS.Dvmap.a .


The distribution of rooting malware through Google Play is not a new thing .


For example , the Ztorg Trojan has been uploaded to Google Play almost 100 times since September 2016 .


But Dvmap is very special rooting malware .


It uses a variety of new techniques , but the most interesting thing is that it injects malicious code into the system libraries – libdmv.so or libandroid_runtime.so .


This makes Dvmap the first Android malware that injects malicious code into the system libraries in runtime , and it has been downloaded from the Google Play Store more than 50,000 times .


Kaspersky Lab reported the Trojan to Google , and it has now been removed from the store .


To bypass Google Play Store security checks , the malware creators used a very interesting method : they uploaded a clean app to the store at the end of March , 2017 , and would then update it with a malicious version for short period of time .


Usually they would upload a clean version back on Google Play the very same day .


They did this at least 5 times between 18 April and 15 May .


All the malicious Dvmap apps had the same functionality .


They decrypt several archive files from the assets folder of the installation package , and launch an executable file from them with the name “ start. ” The interesting thing is that the Trojan supports even the 64-bit version of Android , which is very rare .


All encrypted archives can be divided into two groups : the first comprises Game321.res , Game322.res , Game323.res and Game642.res – and these are used in the initial phase of infection , while the second group : Game324.res and Game644.res , are used in the main phase .


Initial phase During this phase , the Trojan tries to gain root rights on the device and to install some modules .


All archives from this phase contain the same files except for one called “ common ” .


This is a local root exploit pack , and the Trojan uses 4 different exploit pack files , 3 for 32-bit systems and 1 for 64-bit-systems .


If these files successfully gain root rights , the Trojan will install several tools into the system .


It will also install the malicious app “ com.qualcmm.timeservices. ” These archives contain the file “ .root.sh ” which has some comments in Chinese : Main phase In this phase , the Trojan launches the “ start ” file from Game324.res or Game644.res .


It will check the version of Android installed and decide which library should be patched .


For Android 4.4.4 and older , the Trojan will patch method _Z30dvmHeapSourceStartupBeforeForkv from libdvm.so , and for Android 5 and newer it will patch method nativeForkAndSpecialize from libandroid_runtime.so .


Both of these libraries are runtime libraries related to Dalvik and ART runtime environments .


Before patching , the Trojan will backup the original library with a name bak_ { original name } .


During patching , the Trojan will overwrite the existing code with malicious code so that all it can do is execute /system/bin/ip .


This could be very dangerous and cause some devices to crash following the overwrite .


Then the Trojan will put the patched library back into the system directory .


After that , the Trojan will replace the original /system/bin/ip with a malicious one from the archive ( Game324.res or Game644.res ) .


In doing so , the Trojan can be sure that its malicious module will be executed with system rights .


But the malicious ip file does not contain any methods from the original ip file .


This means that all apps that were using this file will lose some functionality or even start crashing .


Malicious module “ ip ” This file will be executed by the patched system library .


It can turn off “ VerifyApps ” and enable the installation of apps from 3rd party stores by changing system settings .


Furthermore , it can grant the “ com.qualcmm.timeservices ” app Device Administrator rights without any interaction with the user , just by running commands .


It is a very unusual way to get Device Administrator rights .


Malicious app com.qualcmm.timeservices As I mentioned before , in the “ initial phase ” , the Trojan will install the “ com.qualcmm.timeservices ” app .


Its main purpose is to download archives and execute the “ start ” binary from them .


During the investigation , this app was able to successfully connect to the command and control server , but it received no commands .


So I don ’ t know what kind of files will be executed , but they could be malicious or advertising files .


Conclusions This Trojan was distributed through the Google Play Store and uses a number of very dangerous techniques , including patching system libraries .


It installs malicious modules with different functionality into the system .


It looks like its main purpose is to get into the system and execute downloaded files with root rights .


But I never received such files from their command and control server .


These malicious modules report to the attackers about every step they are going to make .


So I think that the authors are still testing this malware , because they use some techniques which can break the infected devices .


But they already have a lot of infected users on whom to test their methods .


I hope that by uncovering this malware at such an early stage , we will be able to prevent a massive and dangerous attack when the attackers are ready to actively use their methods .


MD5 43680D1914F28E14C90436E1D42984E2 20D4B9EB9377C499917C4D69BF4CCEBE First widely distributed Android bootkit Malware infects more than 350,000 Devices January 29 , 2014 In the last quarter of 2013 , sale of a Smartphone with ANDROID operating system has increased and every second person you see is a DROID user .


A Russian security firm 'Doctor Web ' identified the first mass distributed Android bootkit malware called 'Android.Oldboot ' , a piece of malware that 's designed to re-infect devices after reboot , even if you delete all working components of it .


The bootkit Android.Oldboot has infected more than 350,000 android users in China , Spain , Italy , Germany , Russia , Brazil , the USA and some Southeast Asian countries .


China seems to a mass victim of this kind of malware having a 92 % share .


A Bootkit is a rootkit malware variant which infects the device at start-up and may encrypt disk or steal data , remove the application , open connection for Command and controller .


A very unique technique is being used to inject this Trojan into an Android system where an attacker places a component of it into the boot partition of the file system and modify the 'init ' script ( initialize the operating system ) to re-load the malware as you switch on your android .


When you start your device , this script loads the Trojan 'imei_chk ' ( detects it as Android.Oldboot.1 ) which extract two files libgooglekernel.so ( Android.Oldboot.2 ) and GoogleKernel.apk ( Android.Oldboot.1.origin ) , copy them respectively in /system/lib and /system/app .


Android.Oldboot acts as a system service and connects to the command-and-controller server using libgooglekernel.so library and receives commands to download , remove installed apps , and install malicious apps .


Since it becomes a part of the boot partition , formatting the device will not solve the problem .


The researchers believe that the devices somehow had the malware pre-loaded at the time of shipping from the manufacturer , or was likely distributed inside modified Android firmware .


So , users should beware of certain modified Android firmware .


Two weeks ago , Some Chinese Security Researchers have also detected a bootkit called 'Oldboot ' , possibly the same malware or another variant of it .


" Due to the special RAM disk feature of Android devices ' boot partition , all current mobile antivirus products in the world ca n't completely remove this Trojan or effectively repair the system .


'' " According to our statistics , as of today , there 're more than 500 , 000 Android devices infected by this bootkit in China in last six months .


The Android malware Android.Oldboot is almost impossible to remove , not even with formatting your device .


But if your device is not from a Chinese manufacturer , then chances that you are a victim of it , are very less .


This bootkit is not the first of this kind .


Two years back , in the month of March we reported , NQ Mobile Security Research Center uncovered the world 's first Android bootkit malware called 'DKFBootKit ' , that replaces certain boot processes and can begin running even before the system is completely booted up .


But Android.Oldboot malware is a bit more dangerous because even if you remove all working components of it from your android successfully , the component imei_chk will persist in a protected boot memory area and hence will reinstall itself on next boot and continuously infect the Smartphone .


Users are recommended to install apps from authorized stores such as Google Play , disable installation of apps from 'Unknown Sources ' and for a better security install a reputed security application .


You can also try to re-flash your device with its original ROM .


After flashing , the bootkit will be removed .


FrozenCell : Multi-Platform Surveillance Campaign Against Palestinians October 5 , 2017 FrozenCell has been seen masquerading as various well known social media and chat applications as well as an app likely only used by Palestinian or Jordanian students sitting their 2016 general exams .


Lookout researchers have discovered a new mobile surveillanceware family , FrozenCell .


The threat is likely targeting employees of various Palestinian government agencies , security services , Palestinian students , and those affiliated with the Fatah political party .


FrozenCell is the mobile component of a multi-platform attack we 've seen a threat actor known as " Two-tailed Scorpion/APT-C-23 , '' use to spy on victims through compromised mobile devices and desktops .


The desktop components of this attack , previously discovered by Palo Alto Network , are known as KasperAgent and Micropsia .


We discovered 561MB of exfiltrated data from 24 compromised Android devices while investigating this threat .


More data is appearing daily , leading us to believe the actors are still highly active .


We are continuing to watch it closely .


This threat is another proof point that attackers are clearly incorporating the mobile device into their surveillance campaigns as a primary attack vector .


Government agencies and enterprises should look at this threat as an example of the kind of spying that is now possible given how ubiquitous mobile devices are in the workplace .


Attackers are keenly aware of the information they can derive from these devices and are using multi-stage ( phishing + an executable ) , multi-platform ( Android + desktop ) attacks to accomplish their spying .


All Lookout customers are protected from this threat .


What it does FrozenCell masquerades as fake updates to chat applications like Facebook , WhatsApp , Messenger , LINE , and LoveChat .


We also detected it in apps targeted toward specific Middle Eastern demographics .


For example , the actors behind FrozenCell used a spoofed app called Tawjihi 2016 , which Jordanian or Palestinian students would ordinarily use during their general secondary examination .


Once installed on a device FrozenCell is capable of : Recording calls Retrieving generic phone metadata ( e.g. , cell location , mobile country code , mobile network code ) Geolocating a device Extracting SMS messages Retrieving a victim 's accounts Exfiltrating images Downloading and installing additional applications Searching for and exfiltrating pdf , doc , docx , ppt , pptx , xls , and xlsx file types Retrieving contacts The graph below represents a split of the types of data


from only one misconfigured command and control server ( out of over 37 servers ) .


This is only a small picture of the threat actor 's operations .


Split of exfiltrated data Some noteworthy files identified in content taken from compromised devices include passport photos , audio recordings of calls , other images , and a PDF document with data on 484 individuals .


The PDF lists dates of birth , gender , passport numbers , and names .


Potential targets The actors behind FrozenCell used an online service that geolocates mobile devices based on nearby cell towers to track targets .


This data shows a distinct concentration of infected devices beaconing from Gaza , Palestine .


Map of potential targets Early samples of FrozenCell used an online service for storing geolocation information of infected devices .


Analysis of this telemetry shows infected devices are completely based in Gaza , Palestine .


It has not been confirmed whether these are from test devices or the devices of victims .


We were also able to link the FrozenCell 's Android infrastructure to numerous desktop samples that are part of the larger multi-platform attack .