## Cyberespionage Campaign Sphinx Goes Mobile With AnubisSpy Technical BriefTrendLabs Security Intelligence BlogEcular Xuand Grey GuoMobile Threat Response TeamDecember2017 ----- # Table of Contents Campaign Analysis ....................................................................................................................................... 2 Correlation ..................................................................................................................................................... 6 AnubisSpy’s Capabilities .............................................................................................................................. 8 AnubisSpy’s Modules ................................................................................................................................... 9 Init Module ................................................................................................................................................................. 9 Patch Module .......................................................................................................................................................... 12 Comm Module ......................................................................................................................................................... 13 DBDump Module ..................................................................................................................................................... 15 Position Module ....................................................................................................................................................... 18 Screenshot Module ................................................................................................................................................. 19 CMD Module ........................................................................................................................................................... 20 Audio Record, Calls, and VoIP Modules .................................................................................................................. 22 Destruction Module ................................................................................................................................................. 25 Dec Module ............................................................................................................................................................. 25 Enc Module.............................................................................................................................................................. 26 Format Module ........................................................................................................................................................ 27 Uploader Module ..................................................................................................................................................... 28 Indicators of Compromise (IoCs) ................................................................................................................ 30 TREND MICRO LEGAL DISCLAIMER The information provided herein is for general information and educational purposes only. It is not intended and should not be construed to constitute legal advice. The information contained herein may not be applicable to all situations and may not reflect the most current situation. Nothing contained herein should be relied on or acted upon without the benefit of legal advice based on the particular facts and circumstances presented and nothing herein should be construed otherwise. Trend Micro reserves the right to modify the contents of this document at any time without prior notice. Translations of any material into other languages are intended solely as a convenience. Translation accuracy is not guaranteed nor implied. If any questions arise related to the accuracy of a translation, please refer to the original language official version of the document. Any discrepancies or differences created in the translation are not binding and have no legal effect for compliance or enforcement purposes. Although Trend Micro uses reasonable efforts to include accurate and up-to-date information herein, Trend Micro makes no warranties or representations of any kind as to its accuracy, currency, or completeness. You agree that access to and use of and reliance on this document and the content thereof is at your own risk. Trend Micro disclaims all warranties of any kind, express or implied. Neither Trend Micro nor any party involved in creating, producing, or delivering this document shall be liable for any consequence, loss, or damage, including direct, indirect, special, consequential, loss of business profits, or special damages, whatsoever arising out of access to, use of, or inability to use, or in connection with the use of this document, or any errors or omissions in the content thereof. Use of this information constitutes acceptance for use in an “as is” condition. ----- [Android malware like ransomware exemplify how the platform can be lucrative for cybercriminals. But](http://blog.trendmicro.com/trendlabs-security-intelligence/android-mobile-ransomware-evolution/) there are also other threats stirring up as of late: attacks that spy on and steal data from specific targets. More than the malware involved, these also demonstrate how attackers are crossing over between desktops and their mobile counterparts. Take for instance several malicious apps we came across with cyberespionage capabilities, targeting Arabic-speaking users or Middle Eastern countries. These were published on Google Play — but have since been taken down — and third-party app marketplaces. We named these malicious apps AnubisSpy (ANDROIDOS_ANUBISSPY) as all the malware’s payload is a package called watchdog. We construe AnubisSpy to be linked to the cyberespionage campaign [Sphinx (APT-C-15)](http://b.360.cn/assets/doc/apt_report/en/Sphinx-Targeted%20cyber-attack%20in%20the%20Middle%20East.pdf) based on shared file structures and command-and-control (C&C) server as well as targets. It’s also possible that while AnubisSpy’s operators may also be Sphinx’s, they could be running separate but similar campaigns. We disclosed our findings to Google and worked with them to take down the apps on Google Play. Updates were also made to [Google Play Protect to take appropriate action against those apps that have](https://www.android.com/play-protect/) been verified as in violation of Google Play policy. This technical brief provides an in-depth analysis of AnubisSpy, along with indicators of compromise (IoCs). Campaign Analysis There were at least seven apps signed with the same fake Google certificate. We found two more apps made by the same developer, but they had no espionage-related codes. Based on hardcoded strings in the Agent Version, the malicious apps were created as early as April 2015. Timestamps indicate that the earliest sample was signed on June 2015 while the latest variant was signed on May 2017. Figure 1: Agent Version of one of the AnubisSpy variants (top) and timestamps of when they were signed (bottom) AnubisSpy wasn’t only published on Google Play; variants of it were also in third-party app marketplaces. An AnubisSpy variant, named م ت ضام نون مع ال س ي سي, which translates to “In Solidarity with Sisi,” poses as a promotional app (SisiFans) targeting the supporters of a political figure. It had 150 installs before it was taken off Google Play after our disclosure. The developer’s handle, ss4mDEV, also appears in other app marketplaces. The Google Play-hosted AnubisSpy was developed by TVDEV, whom we encountered in other marketplaces. We reported our [findings to Google, and Google Play Protect accordingly detected and pulled the Google Play-hosted](https://www.android.com/play-protect/) apps developed by TVDEV. ----- SisiFans is also on another third-party app story we saw uploaded last February 27. ss4mDEV also uploaded another AnubisSpy version in the form of a healthcare-related app called SwiftClinic. Both apps share the same certificate. SwiftClinic, touting multilingual support, masqueraded as a patient registration application for dental clinics. It was also shortly published on Google Play, but was promptly taken down. Figure 2: AnubisSpy disguising as a healthcare-related app Figure 3: Properties of AnubisSpy as SwiftClinic ----- AnubisSpy was also in another third-party app marketplace in the form of apps with the package name nms.sabayaElkher. We also found apps developed by TVDEV. One posed as an aggregator of news covering Egypt’s government and politics. While it had no espionage functionalities (it had a different certificate, too), we think this was an experimental project considering it was released back in 2016, before the latest versions of AnubisSpy made their way to Google Play and third-party app marketplaces. TVDEV also developed and uploaded a similar app named officialsabayaelkheer on March 14, 2017. It poses as an app for “Sabaya El Kheir,” a TV program in Egypt. officialsabayaelkheer may just be a Potentially Unwanted Application (PUA) with no espionage functions, but it has the same nms.sabayaElkher label, which it shares with AnubisSpy-laden apps. We think these seemingly innocuous apps and versions of AnubisSpy were created during the same period so the latter can better camouflage and hide from antivirus (AV) detection. Figure 4: Screenshot of an app posing as an aggregator for news in Egypt ----- Figure 5: AnubisSpy on a Spanish third-party app marketplace Figure 6: Screenshots of the app TVDEV developed, which posed as the official app of an Egypt-based TV program ----- [Sphinx reportedly uses the watering hole technique via social media sites to deliver its payloads —](https://www.trendmicro.com/vinfo/us/threat-encyclopedia/web-attack/137/watering-hole-101) [mainly a customized version of njRAT. The Sphinx campaign operators cloaked their malware with Word,](http://blog.trendmicro.com/trendlabs-security-intelligence/new-rats-emerge-from-leaked-njw0rm-source-code/) PDF, image, and application (i.e., Flash) icons to dupe recipients into clicking them. Sphinx was active between June 2014 and November 2015, but timestamps of the malware indicate the attacks started as early as 2011. A WHOIS query of the C&C server showed that it abused a legitimate managed hosting service provider based in Belize. We correlated these AnubisSpy variants to Sphinx’s desktop/PC-targeting malware given these commonalities: - They share the same C&C server IP address, 86[.]105[.]18[.]107 - They share the technique of decrypting JSON files; the file structures of AnubisSpy and Sphinx’s malware are similar - Their targets are highly concentrated in the Middle East Figure 7: Comparison of file structure in Sphinx’s desktop/PC-targeting malware (left) and AnubisSpy (right) The apps mainly used Middle East-based news and sociopolitical themes as social engineering hooks, and abused social media to further proliferate. For instance, an app developed by TVDEV (nms.sabayaElkher) went to great lengths to feign as a legitimate app. It had three additional tabs/screens, each of which pointed to its Facebook, Twitter, and Google Play pages. The apps were all written in Arabic and, in one way or another, related to something in Egypt (i.e., spoofing an Egypt-based TV program and using news/stories in the Middle East) regardless of the labels and objects within the apps. Our coordination with Google also revealed that these apps were installed across a handful of countries in the Middle East. ----- Figure 8: An app developed by TVDEV (nms.sabayaElkher) posing as a legitimate app; note the screens and icons for its Facebook and Twitter pages ----- The malicious modules of all the AnubisSpy samples are almost the same. Our analyses are from a sample with the package name cc.solidaritycc (SHA256: d627f9d0e2711d59cc2571a11d16c950adadba55d95fd4c55638af6a97d32b23). AnubisSpy can steal messages (SMS), photos, videos, contacts, email accounts, calendar events, and browser histories (i.e., Chrome and Samsung Internet Browser). It can also take screenshots and record audio, including calls. It can monitor the victim through apps installed on the device, such as Skype, WhatsApp, Facebook, and Twitter, among others. After the data are collected, they are encrypted and sent to the (C&C) server. AnubisSpy can also selfdestruct to cover its tracks. It can run commands and delete files on the device, as well as install and uninstall Android Application Packages (APKs). AnubisSpy’s code is well constructed, indicating at least the attackers’ know-how. Below is a visualization of the modules: Figure 9: Structure of AnubisSpy’s modules ----- The Init Module initiates all the other spyware modules and prepares the running environment. It sleeps for 60 seconds, then calls the Dec Module to decrypt two JavaScript Object Notation (JSON) files and a ZIP file from the assets folder. Sleep 60s Decrypt rule file Decrypt configure file Decrypt supers-related files Figure 10: Init Module’s routine The first JSON file has "Agent configuration." All modules are initiated based on this configuration file. It has two main parts: “core” and “plugins.” The former contains detailed spyware and global configurations, while the latter mainly has configurations about communication, such as the C&C address used for initiating the Comm Module. The second JSON file is a so-called dbrule file. Each item within it has extensive rules for stealing sensitive information. “uri” indicates the Universal Resource Identifier (URI) of Android SMS; “sort_order” and “selection” are for querying the database. In short, the first configuration file specifies what to do, while the dbrule file specifies how to do it. The decrypted ZIP file is used as Patch Module. Sleep 60s Decrypt rule file Decrypt configure file Decrypt supers-related files ----- Figure 11: dbrule file’s rule for stealing SMS messages (left) and the list of apps AnubisSpy monitors (right) Init CMD Module Init DBdump Module Init Screenshots Module Init Position Module Init Uploader Module Init Comm Module Init APK Manipulate Module Figure 12: Code snippets showing how the Init Module initiates the spying-related modules after getting the configuration file Init CMD Module Init DBdump Module Init Screenshots Module Init Position Module Init CMD Module ----- [Figure 13: Code snippet showing how Init Module uses ContentObserver](https://developer.android.com/reference/android/database/ContentObserver.html) [The Init Module initiates serials of ContentObserver (used for tracking changes in the device’s data),](https://developer.android.com/reference/android/database/ContentObserver.html) based on the configuration file. This includes SMS, calendar events, emails, browsing histories in Chrome and Samsung Internet Browser, photos, and videos. If any of the device content changes, a specific module will be invoked to process the new/updated data. Figure 14: Code snapshot showing how new/changed data is processed Based on the configuration and device-rooted status, it will call the Android Application Package (APK) Manipulate Module to install itself as a system application then install an embedded APK decrypted from assets. In one of the samples we analyzed though, there was no embedded APK in the assets folder. Decrypt embedded APK Install embedded APK Install itself into /system/app Figure 15: Code snapshot showing the Manipulate Module Decrypt embedded APK Install embedded APK Install itself into /system/app ----- Some of the spying-related modules need root permission. The Patch Module is for rooted devices, deploying root-related functionalities and granting the malware root permission without user knowledge. The Init Module first checks the device’s root status. Based on the "no_supersu_patch" configuration (True or False), a file (ZIP) is decrypted. Figure 16: Init Module checking the root status (top); configuration code checking if a ZIP file should be decrypted (center); and the ZIP file’s structure (bottom) A series of commands is performed to deploy files on the device, and is carried out by a bash script named “update-binary.” It will patch/change the superSU configuration file, if existing, to grant itself root permission and ensure no notifications, logs, and re-authentication are made. ----- Figure 17: update-binary deploying files on the device (top) and how Patch Module grants root permission (bottom) Comm Module The Comm Module plays the middleman between the agent and the C&C server. It is initiated based on the configuration file, with the C&C server address and service path as the key parameters. All communications are performed through HTTP/HTTPS POST method using multipart/form-data requests. It has these main types of communications: sending and retrieving a file to and from the server, as well as getting commands from the server. ----- Figure 18: Snapshot of the Comm Module Keywords replacement Figure 19: Code snippets showing how the Comm Module works Keywords replacement ----- To evade traffic inspection, all keywords in the request body are replaced based on protocol_strings specified in the configuration file: Original Keyword Replaced Keyword request choux type lobotomize put whispered get hillo ip idolizers list deliberate del luff event damageable command telescopes timestamp carillon file chevins filename triggered filelist hurras status snuffler chunknum debriefs Table 1: Keywords based on protocol_strings DBDump Module The DBDump Module consists of two parts: DUMP_DATABASES_EXACT_TIME and DUMP_DATABASES_INTERVAL, which are initiated by separate configurations. DUMP_DATABASES_EXACT_TIME dumps specific databases at an exact time. Its configuration contains a time and dump list. In this case, it’s supposed to dump the device’s contact information at a certain time. This function though is disabled as there’s no value for the “time.” However, it still can be enabled through a configuration update from the C&C server. Some of the routines specified in the code need root permission. Figure 20: Code snapshots showing the DBDump Module’s DUMP_DATABASES_EXACT_TIME |:|Col2| |---|---| |Original Keyword|Replaced Keyword| |request|choux| |type|lobotomize| |put|whispered| |get|hillo| |ip|idolizers| |list|deliberate| |del|luff| |event|damageable| |command|telescopes| |timestamp|carillon| |file|chevins| |filename|triggered| |filelist|hurras| |status|snuffler| |chunknum|debriefs| ----- DUMP_DATABASES_INTERVAL dumps specific databases at intervals. Its configuration contains the interval time and specified databases. In this case, the following are configured: Time Interval dbItem device/sms 10 minutes device/calls device/calendar_events facebook/messages facebook/notifications linkedin/messages twitter/tweets gplus/activities viber/messages viber/calls whatsapp/messages hangout-gtalk/messages skype/messages skype/calls gmail/emails system_email/emails device/browser_history_chrome device/browser_history_samsung device/browser_history device/photo device/video google_play_service_security/* 72 hours system_email/accounts system_users_security/* device/contacts gplus/contacts viber/contacts skype/contacts whatsapp/contacts facebook/contacts linkedin/profiles linkedin/connections twitter/following Table 2: Database items dumped by the DBDump Module The DBDump Module dumps databases only when the screen is off to evade users’ awareness. For every item above, it will look into the dbrule file to get the corresponding rule. |Time Interval|dbItem| |---|---| |10 minutes|device/sms| ||device/calls| ||device/calendar_events| ||facebook/messages| ||facebook/notifications| ||linkedin/messages| ||twitter/tweets| ||gplus/activities| ||viber/messages| ||viber/calls| ||whatsapp/messages| ||hangout-gtalk/messages| ||skype/messages| ||skype/calls| ||gmail/emails| ||system_email/emails| ||device/browser_history_chrome| ||device/browser_history_samsung| ||device/browser_history| ||device/photo| ||device/video| |72 hours|google_play_service_security/*| ||system_email/accounts| ||system_users_security/*| ||device/contacts| ||gplus/contacts| ||viber/contacts| ||skype/contacts| ||whatsapp/contacts| ||facebook/contacts| ||linkedin/profiles| ||linkedin/connections| ||twitter/following| ----- Below is an example rule for facebook/messages. It tells the DBDump Module Facebook’s root directory and asks for database location and file name, SQL query statement, and other field titles for further result formatting. Figure 21: Rule used by the DBDump Module for facebook/messages It then gets and parses rules then queries db and sends the information to the Format Module: Figure 22: DBDump Module parsing the rules (top), and querying the db (bottom) ----- The Position Module retrieves the device’s location data and uploads it to the C&C server. A parameter of position_interval in the configuration file is sent to the Position Module when initiating. It indicates the intervals for when location data (position) is stolen each time. In a sample we analyzed (shown below), the value is 600 — that is, the Position Module collects and uploads this information every 10 minutes. Figure 23: Position Module indicating the interval time for stealing location data Each time that it collects the data, if there’s a position/location, it selects a specific Position Provider via GPS, network or passive (last known location), whether the device’s screen is on or off. If force_location_services_enabled is configured, it will try to enable the GPS and network provider. The device’s location/position data is sent to the Format Module, then processed as a JSON file with value of key “type” as “gis.” Figure 24: How the Position Module selects the Position Provider (top), enables GPS and network provider (center), and passes the information to the Format Module (bottom) ----- The Screenshot Module takes screenshots and uploads them to the C&C server. It reads related configurations from the configuration file first before initiating. Apart from time intervals, there’s also a package list in the configuration set that the Screenshot Module uses when taking screenshots. The Screenshot Module works only on rooted devices. Figure 25: Screenshot Module’s intervals for taking screenshots (top) and how it checks whether the device is rooted or not (bottom) It first gets the device’s current, overlaying activity. It takes a screenshot of it if its package name is in the list from its configuration file. If it fails to get the activity or if the package list is empty, it will just take a screenshot of current screen regardless of the activities running on top. A screenshot is taken by running screencap. After it is compressed, it is sent to the Format Module and processed as a JSON file whose value key “type” is “image,” and accompanied with other image attributes. The package names listed in the configuration file include: - com.skype.raider - com.facebook.katana - com.facebook.orca - com.whatsapp - com.viber.voip - com.google.android.talk - com.sec.android.app.sbrowser - com.android.chrome - mobi.mgeek.TunnyBrowser ----- Figure 26: Code snippet showing how screenshots are taken (top, center) and how they are processed (bottom) ## CMD Module The CMD Module retrieves commands from the C&C server and processes them. The parameter checkcmd_interval in the configuration file is sent to the CMD Module when initiating. It indicates the interval for checking/awaiting commands (CMD checking) from the C&C server. As shown below, the value is 600 — that is, the CMD Module checks for commands from the C&C server every 10 minutes. Figure 27: CMD Module’s interval for checking commands ----- Figure 28: CMD Module calling the Destruction Module (top) and encryption of commands (bottom) Before sending a CMD request to the C&C server, it checks if the current date reached the "expiry_date," which is read from the configuration file. If it has, it will call the Destruction Module to remove itself from the device; otherwise, it proceeds to do CMD checking. Getting the command from the C&C server is performed through the Comm Module. The commands are sent in JSON format then encrypted. After getting the raw data, the CMD Module calls the Dec Module to decrypt it then parse it as a JSON file. The JSON file’s contents have these commands: Command Comments uninstall_agent Destruct itself install_package Install an APK, which is sent from the C&C server and encoded in command JSON file uninstall_package Uninstall a specific package update_config Update the configuration file update_dbrules Update the dbrule file get_databases Dump a specific db get_file Get and upload specific files on the device recv_file Retrieve a file from the C&C server and put it in a certain location on the device exec_cmdline Run command line on the device delete_file Delete a specific file from the device get_dirtree Get and upload a specific directory tree structure get_sysinfo Call the Device Info Module to get system information start_av_bug Start audio recording through Audio Record Module stop_av_bug Stop audio recording through Audio Record Module Table 3: Commands from the C&C server |Command|Comments| |---|---| |uninstall_agent|Destruct itself| |install_package|Install an APK, which is sent from the C&C server and encoded in command JSON file| |uninstall_package|Uninstall a specific package| |update_config|Update the configuration file| |update_dbrules|Update the dbrule file| |get_databases|Dump a specific db| |get_file|Get and upload specific files on the device| |recv_file|Retrieve a file from the C&C server and put it in a certain location on the device| |exec_cmdline|Run command line on the device| |delete_file|Delete a specific file from the device| |get_dirtree|Get and upload a specific directory tree structure| |get_sysinfo|Call the Device Info Module to get system information| |start_av_bug|Start audio recording through Audio Record Module| |stop_av_bug|Stop audio recording through Audio Record Module| ----- The Audio Record Module records audio, mainly used by the CMD Module, and calls-related modules. It is referred to in the configuration file via the strings media_chunk_size and audio_hq. After it records the audio, it is sent as a pass result file (along with other information such as Location and DialNumber) to the Format Module. The Calls Module monitors and records the device’s incoming and outgoing call actions. The configuration file refers to it via the strings call_info, call_audio, audio_hq, and media_chunk_size. Figure 29: Code snippets showing the Audio Record (top) and Calls modules (center, bottom) When a call action occurs, the Calls Module determines the phoneNumber and action type (outgoing or incoming), and invokes the Audio Record Module. The captured audio record file is sent to the Format Module along with information such as call type, phoneNumber, phoneNumber displayName, Location, and currentTime. ----- Figure 30: How the captured audio is processed (top) and code snippets showing how the VoIP Module works (center, bottom) The VoIP Module monitors calls done on Voice over Internet Protocol (VoIP) by registering android.service.notification.NotificationListenerService. When receiving a Notification Action, it checks if the notification is specified in a list of packages in the configurations file. If it finds a match, it is further processed (i.e., invoking the Audio Record Module). ----- The Device Info Module collects the following information on the device’s operating system (OS), build, and phone information, and the device’s root status and apps: root status arch OS INFO osname osversion board BUILD INFO bootloader branch cpu abi device display fingerprint hardware host id manufacturer model product radio serial tags time Type user device_memory PHONE INFO media_storage_totalspace media_storage_freespace local_time current_position imei imsi sw_version line_number voicemail_number network_country_iso network_operator device_type network_type sim_country_iso sim_operator sim_serial_number sim_state installed_app_list Table 4: Information that Device Info Module collects |Col1|root status| |---|---| |OS INFO|arch| ||osname| ||osversion| |BUILD INFO|board| ||bootloader| ||branch| ||cpu abi| ||device| ||display| ||fingerprint| ||hardware| ||host| ||id| ||manufacturer| ||model| ||product| ||radio| ||serial| ||tags| ||time| ||Type| ||user| |PHONE INFO|device_memory| ||media_storage_totalspace| ||media_storage_freespace| ||local_time| ||current_position| ||imei| ||imsi| ||sw_version| ||line_number| ||voicemail_number| ||network_country_iso| ||network_operator| ||device_type| ||network_type| ||sim_country_iso| ||sim_operator| ||sim_serial_number| ||sim_state| ||installed_app_list| ----- This module is for when expire_time is reached, or if executing a self-destruct command. First, it tries to remove its device-admin permission, stops the spying-related modules’ schedule, and unregisters ContentObservers. It then removes itself from the device. Figure 31: How the Destruction Module works (top) and how it removes itself from the device (bottom) Dec Module The Dec Module is for decrypting encrypted assets and data from the C&C server using the Advanced Encryption Standard (AES) algorithm. The following keys, which are hardcoded, are used for decryption: - SecretKey — 001234ABDE9217910000DEC4FEDB120003243BC00221296470103FE000AAB201 - IvParameter — 001234abde9217910000dec4fedb1200 When decrypting data from the C&C server, it reads SecretKey, which is "cipher_key" in the configuration file. To get IvParameter, it reads the first 32 bytes of data and decrypts them using the table keys. Both SecretKey and IvParameter are used to decrypt the rest of the data. ----- Figure 32: Dec Module using AES to decrypt assets Enc Module All data are processed by the Enc Module before they are uploaded to the C&C server. Like Dec Module, it uses AES. SecretKey is read from the configuration file (cipher_key), but the IvParameter here is generated randomly. Data are encrypted into two parts (bodyPart, headPart) via different parameters. bodyPart is encrypted through cipher_key and a randomly generated IvParameter, which is headPart’s data. IvParameter is encrypted via the default SecretKey and IvParameter. It is combined as one file and sent to the Uploader Module. Figure 33: How the Enc Module works ----- The outputs of AnubisSpy’s modules vary, which makes the Format Module very complex and diverse. But amid the complexity, there are common denominators. All data are processed into JSON files by the Format Module. AnubisSpy’s modules have two data types: - String — Device information, SMS messages, etc. - Binary — Images, audio files, etc. For String data, the Format Module will process it to a JSON file based on the module. It will retrieve rules and items from the configuration file’s dbruleFile to construct the JSON file. Figure 34: Code snippets showing the rules being retrieved (top), as well as column value and field title replacements for the DBDump Module ----- For Binary data, the same process is carried out, but more file attribution such as file path, size, timestamp, etc., are added. The binary data is base64-encoded with the key binary_data. Figure 35: Binary data base64-encoded (top); sample information written in the resulting JSON file for captured audio (center) and image (bottom) Uploader Module AnubisSpy’s modules send their outputs into one specific folder after they are encrypted. The Uploader Module is responsible for checking, uploading, and deleting them. There are two configurations that tell the Uploader Module when to work: when there’s a Wi-Fi connection, and when the device’s battery is being charged. File traverse in the cache folder, sent, then removed. It sleeps from 3-5 seconds when it processes a file. ----- Figure 36: Uploader Module works only as specified in the configuration file What does AnubisSpy mean to the mobile landscape? Persistent and furtive spyware is an underrated problem for the mobile platform. While cyberespionage campaigns on mobile devices may be few and far between compared to ones for desktops or PCs, AnubisSpy proves that they do indeed occur, and may have been more active than initially thought. Will mobile become cyberespionage’s main frontier? It won’t be a surprise given the mobile platform’s [increasing ubiquity, especially in workplaces.](https://www.gartner.com/newsroom/id/3725117) [Beyond its impact, AnubisSpy also highlights the significance of proactively securing mobile devices,](https://www.trendmicro.com/vinfo/us/security/news/mobile-safety/best-practices-securing-your-mobile-device) [particularly if they’re on BYOD programs and used to access sensitive data. Enforcing the principle of](https://www.trendmicro.com/vinfo/us/security/news/cybercrime-and-digital-threats/-infosec-guide-bring-your-own-device-byod) least privilege and implementing an app reputation system are just some of the best practices that can help mitigate threats. We disclosed our findings to Google and worked with them to take down the apps on Google Play. Updates were also made to [Google Play Protect to take appropriate action against those apps that have](https://www.android.com/play-protect/) been verified as in violation of Google Play policy. ----- Indicators of Compromise (IoCs)Hashes detected as ANDROIDOS_ANUBISSPY(SHA256): Hash 627f9d0e2711d59cc2571a11d16c950adadba55d95fd4c55638af6a97d32b23 صبايا الخير e00655d06a07f6eb8e1a4b1bd82eefe310cde10ca11af4688e32c11d7b193d95 SwiftClinic 06cb3f69ba0dd3a2a7fa21cdc1d8b36b36c2a32187013598d3d51cfddc829f49 ALTOR 0cab88bb37fee06cf354d257ec5f27b0714e914b8199c03ae87987f6fa807efc 7eeadfe1aa5f6bb827f9cb921c63571e263e5c6b20b2e27ccc64a04eba51ca7a C.Sinai 0714b516ac824a324726550b45684ca1f4396aa7f372db6cc51b06c97ea24dfd C.Sinai ad5babecf3a21dd51eee455031ab96f326a9dd43a456ce6e8b351d7c4347330f Tsina C&C servers linked to AnubisSpy: C&C Server hxxp://86[.]105[.]18[.]107/2dodo/loriots[.]php hxxp:// 86[.]105[.]18[.]107/111fash7/synectics[.]php hxxp:// 86[.]105[.]18[.]107/3hood/spelled[.]php hxxp:// 86[.]105[.]18[.]107/1swiftclinic/entires[.]php hxxp:// 86[.]105[.]18[.]107/7ram/olefiant[.]php hxxp:// 86[.]105[.]18[.]107/sinai/freakiest[.]php |Hash|App Label| |---|---| |627f9d0e2711d59cc2571a11d16c950adadba55d95fd4c55638af6a97d32b23|ريخلا ايابص| |e00655d06a07f6eb8e1a4b1bd82eefe310cde10ca11af4688e32c11d7b193d95|SwiftClinic| |06cb3f69ba0dd3a2a7fa21cdc1d8b36b36c2a32187013598d3d51cfddc829f49|ALTOR| |0cab88bb37fee06cf354d257ec5f27b0714e914b8199c03ae87987f6fa807efc|يسيسلا عم نونماضتم| |7eeadfe1aa5f6bb827f9cb921c63571e263e5c6b20b2e27ccc64a04eba51ca7a|C.Sinai| |0714b516ac824a324726550b45684ca1f4396aa7f372db6cc51b06c97ea24dfd|C.Sinai| |ad5babecf3a21dd51eee455031ab96f326a9dd43a456ce6e8b351d7c4347330f|Tsina C&C servers linked to AnubisSpy:| ----- Trend Micro Incorporated, a global leader in security software, strives to make the world safe for exchanging digital information. Our innovative solutions for consumers, businesses and governments provide layered content security to protect information on mobile devices, endpoints, gateways, servers and the cloud. All of our solutions are powered by cloud-based global threat intelligence, the Trend Micro™ Smart Protection Network™, and are supported by over 1,200 threat experts around the globe. For more information, visit www.trendmicro.com. ©2017 by Trend Micro, Incorporated. All rights reserved. Trend Micro and the Trend Micro t-ball logo are trademarks or registered trademarks of Trend Micro, Incorporated. All other product or company names may be trademarks or registered trademarks of their owners. -----