What is the scope of Chrysaor ?


Chrysaor was never available in Google Play and had a very low volume of installs outside of Google Play .


Among the over 1.4 billion devices protected by Verify Apps , we observed fewer than 3 dozen installs of Chrysaor on victim devices .


These devices were located in the following countries : How we protect you To protect Android devices and users , Google Play provides a complete set of security services that update outside of platform releases .


Users do n't have to install any additional security services to keep their devices safe .


In 2016 , these services protected over 1.4 billion devices , making Google one of the largest providers of on-device security services in the world : Identify PHAs using people , systems in the cloud , and data sent to us from devices Warn users about or blocking users from installing PHAs Continually scan devices for PHAs and other harmful threats Additionally , we are providing detailed technical information to help the security industry in our collective work against PHAs .


What do I need to do ?


It is extremely unlikely you or someone you know was affected by Chrysaor malware .


Through our investigation , we identified less than 3 dozen devices affected by Chrysaor , we have disabled Chrysaor on those devices , and we have notified users of all known affected devices .


Additionally , the improvements we made to our protections have been enabled for all users of our security services .


To ensure you are fully protected against PHAs and other threats , we recommend these 5 basic steps : Install apps only from reputable sources : Install apps from a reputable source , such as Google Play .


No Chrysaor apps were on Google Play .


Enable a secure lock screen : Pick a PIN , pattern , or password that is easy for you to remember and hard for others to guess .


Update your device : Keep your device up-to-date with the latest security patches .


Verify Apps : Ensure Verify Apps is enabled .


Locate your device : Practice finding your device with Android Device Manager because you are far more likely to lose your device than install a PHA .


How does Chrysaor work ?


To install Chrysaor , we believe an attacker coaxed specifically targeted individuals to download the malicious software onto their device .


Once Chrysaor is installed , a remote operator is able to surveil the victim 's activities on the device and within the vicinity , leveraging microphone , camera , data collection , and logging and tracking application activities on communication apps such as phone and SMS .


One representative sample Chrysaor app that we analyzed was tailored to devices running Jellybean ( 4.3 ) or earlier .


The following is a review of scope and impact of the Chrysaor app named com.network.android tailored for a Samsung device target , with SHA256 digest : ade8bef0ac29fa363fc9afd958af0074478aef650adeb0318517b48bd996d5d5Upon installation , the app uses known framaroot exploits to escalate privileges and break Android 's application sandbox .


If the targeted device is not vulnerable to these exploits , then the app attempts to use a superuser binary pre-positioned at /system/csk to elevate privileges .


After escalating privileges , the app immediately protects itself and starts to collect data , by : Installing itself on the /system partition to persist across factory resets Removing Samsung 's system update app ( com.sec.android.fotaclient ) and disabling auto-updates to maintain persistence ( sets Settings.System.SOFTWARE_UPDATE_AUTO_UPDATE to 0 ) Deleting WAP push messages and changing WAP message settings , possibly for anti-forensic purpose .


Starting content observers and the main task loop to receive remote commands and exfiltrate data The app uses six techniques to collect user data : Repeated commands : use alarms to periodically repeat actions on the device to expose data , including gathering location data .


Data collectors : dump all existing content on the device into a queue .


Data collectors are used in conjunction with repeated commands to collect user data including , SMS settings , SMS messages , Call logs , Browser History , Calendar , Contacts , Emails , and messages from selected messaging apps , including WhatsApp , Twitter , Facebook , Kakoa , Viber , and Skype by making /data/data directories of the apps world readable .


Content observers : use Android 's ContentObserver framework to gather changes in SMS , Calendar , Contacts , Cell info , Email , WhatsApp , Facebook , Twitter , Kakao , Viber , and Skype .


Screenshots : captures an image of the current screen via the raw frame buffer .


Keylogging : record input events by hooking IPCThreadState : :Transact from /system/lib/libbinder.so , and intercepting android : :parcel with the interface com.android.internal.view.IInputContext .


RoomTap : silently answers a telephone call and stays connected in the background , allowing the caller to hear conversations within the range of the phone 's microphone .


If the user unlocks their device , they will see a black screen while the app drops the call , resets call settings and prepares for the user to interact with the device normally .


Finally , the app can remove itself through three ways : Via a command from the server Autoremove if the device has not been able to check in to the server after 60 days Via an antidote file .


If /sdcard/MemosForNotes was present on the device , the Chrysaor app removes itself from the device .


Samples uploaded to VirusTotal To encourage further research in the security community , we ’ ve uploaded these sample Chrysaor apps to Virus Total .


Package Name SHA256 digest SHA1 certificate com.network.android ade8bef0ac29fa363fc9afd958af0074478aef650adeb0318517b48bd996d5d5 44f6d1caa257799e57f0ecaf4e2e216178f4cb3d com.network.android 3474625e63d0893fc8f83034e835472d95195254e1e4bdf99153b7c74eb44d86 516f8f516cc0fd8db53785a48c0a86554f75c3ba


Additional digests with links to Chrysaor As a result of our investigation we have identified these additional Chrysaor-related apps .


Package Name SHA256 digest SHA1 certificate com.network.android 98ca5f94638768e7b58889bb5df4584bf5b6af56b188da48c10a02648791b30c 516f8f516cc0fd8db53785a48c0a86554f75c3ba com.network.android 5353212b70aa096d918e4eb6b49eb5ad8f59d9bec02d089e88802c01e707c3a1


44f6d1caa257799e57f0ecaf4e2e216178f4cb3d com.binary.sms.receiver 9fae5d148b89001555132c896879652fe1ca633d35271db34622248e048c78ae 7771af1ad3a3d9c0b4d9b55260bb47c2692722cf com.android.copy e384694d3d17cd88ec3a66c740c6398e07b8ee401320ca61e26bdf96c20485b4


7771af1ad3a3d9c0b4d9b55260bb47c2692722cf com.android.copy 12e085ab85db887438655feebd249127d813e31df766f8c7b009f9519916e389 7771af1ad3a3d9c0b4d9b55260bb47c2692722cf com.android.copy 6348104f8ef22eba5ac8ee737b192887629de987badbb1642e347d0dd01420f8


31a8633c2cd67ae965524d0b2192e9f14d04d016 FinFisher exposed : A researcher ’ s tale of defeating traps , tricks , and complex virtual machines March 1 , 2018 Office 365 Advanced Threat Protection ( Office 365 ATP ) blocked many notable zero-day exploits in 2017 .


In our analysis , one activity group stood out : NEODYMIUM .


This threat actor is remarkable for two reasons : Its access to sophisticated zero-day exploits for Microsoft and Adobe software Its use of an advanced piece of government-grade surveillance spyware FinFisher , also known as FinSpy and detected by Microsoft security products as Wingbird FinFisher is such a complex piece of malware that , like other researchers , we had to devise special methods to crack it .


We needed to do this to understand the techniques FinFisher uses to compromise and persist on a machine , and to validate the effectiveness of Office 365 ATP detonation sandbox , Windows Defender Advanced Threat Protection ( Windows Defender ATP ) generic detections , and other Microsoft security solutions .


This task proved to be nontrivial .


FinFisher is not afraid of using all kinds of tricks , ranging from junk instructions and “ spaghetti code ” to multiple layers of virtual machines and several known and lesser-known anti-debug and defensive measures .


Security analysts are typically equipped with the tools to defeat a good number of similar tricks during malware investigations .


However , FinFisher is in a different category of malware for the level of its anti-analysis protection .


It ’ s a complicated puzzle that can be solved by skilled reverse engineers only with good amount of time , code , automation , and creativity .


The intricate anti-analysis methods reveal how much effort the FinFisher authors exerted to keep the malware hidden and difficult to analyze .


This exercise revealed tons of information about techniques used by FinFisher that we used to make Office 365 ATP more resistant to sandbox detection and Windows Defender ATP to catch similar techniques and generic behaviors .


Using intelligence from our in-depth investigation , Windows Defender ATP can raise alerts for malicious behavior employed by FinFisher ( such as memory injection in persistence ) in different stages of the attack kill chain .


Machine learning in Windows Defender ATP further flags suspicious behaviors observed related to the manipulation of legitimate Windows binaries .


Figure 1 .


Generic Windows Defender ATP detections trigger alerts on FinFisher behavior While our analysis has allowed us to immediately protect our customers , we ’ d like to share our insights and add to the growing number of published analyses by other talented researchers ( listed below this blog post ) .


We hope that this blog post helps other researchers to understand and analyze FinFisher samples and that this industry-wide information-sharing translate to the protection of as many customers as possible .


Spaghetti and junk codes make common analyst tools ineffective In analyzing FinFisher , the first obfuscation problem that requires a solution is the removal of junk instructions and “ spaghetti code ” , which is a technique that aims to confuse disassembly programs .


Spaghetti code makes the program flow hard to read by adding continuous code jumps , hence the name .


An example of FinFisher ’ s spaghetti code is shown below .


Figure 2 .


The spaghetti code in FinFisher dropper This problem is not novel , and in common situations there are known reversing plugins that may help for this task .


In the case of FinFisher , however , we could not find a good existing interactive disassembler ( IDA ) plugin that can normalize the code flow .


So we decided to write our own plugin code using IDA Python .


Armed with this code , we removed this first layer of anti-analysis protection .


Removing the junk instructions revealed a readable block of code .


This code starts by allocating two chunks of memory : a global 1 MB buffer and one 64 KB buffer per thread .


The big first buffer is used as index for multiple concurrent threads .


A big chunk of data is extracted from the portable executable ( PE ) file itself and decrypted two times using a custom XOR algorithm .


We determined that this chunk of data contains an array of opcode instructions ready to be interpreted by a custom virtual machine program ( from this point on referenced generically as “ VM ” ) implemented by FinFisher authors .


Figure 3 .


The stages of the FinFisher multi-layered protection mechanisms Stage 0 : Dropper with custom virtual machine The main dropper implements the VM dispatcher loop and can use 32 different opcodes handlers .


Th 64KB buffer is used as a VM descriptor data structure to store data and the just-in-time ( JIT ) generated code to run .


The VM dispatcher loop routine ends with a JMP to another routine .


In total , there are 32 different routines , each of them implementing a different opcode and some basic functionality that the malware program may execute .


Figure 4 .


A snapshot of the code that processes each VM opcode and the associate interpreter The presence of a VM and virtualized instruction blocks can be described in simpler terms : Essentially , the creators of FinFisher interposed a layer of dynamic code translation ( the virtual machine ) that makes analysis using regular tools practically impossible .


Static analysis tools like IDA may not be useful in analyzing custom code that is interpreted and executed through a VM and a new set of instructions .


On the other hand , dynamic analysis tools ( like debuggers or sandbox ) face the anti-debug and anti-analysis tricks hidden in the virtualized code itself that detects sandbox environments and alters the behavior of the malware .


At this stage , the analysis can only continue by manually investigating the individual code blocks and opcode handlers , which are highly obfuscated ( also using spaghetti code ) .


Reusing our deobfuscation tool and some other tricks , we have been able to reverse and analyze these opcodes and map them to a finite list that can be used later to automate the analysis process with some scripting .


The opcode instructions generated by this custom VM are divided into different categories : Logical opcodes , which implement bit-logic operators ( OR , AND , NOT , XOR ) and mathematical operators Conditional branching opcodes , which implement a code branch based on conditions ( equals to JC , JE , JZ , other similar branching opcodes ) Load/Store opcodes , which write to or read from particular addresses of the virtual address space of the process Specialized opcodes for various purposes ,


like execute specialized machine instruction that are not virtualized We are publishing below the ( hopefully ) complete list of opcodes used by FinFisher VM that we found during our analysis and integrated into our de-virtualization script : INDEX MNEMONIC DESCRIPTION 0x0 EXEC Execute machine code 0x1 JG Jump if greater/Jump if not less or equal 0x2 WRITE Write a value into the dereferenced internal VM value ( treated as a pointer ) 0x3 JNO Jump if not overflow 0x4 JLE Jump


if less or equal ( signed ) 0x5 MOV Move the value of a register into the VM descriptor ( same as opcode 0x1F ) 0x6 JO Jump if overflow 0x7 PUSH Push the internal VM value to the stack 0x8 ZERO Reset the internal VM value to 0 ( zero ) 0x9 JP Jump if parity even 0xA WRITE Write into an address 0xB ADD Add the value of a register to the internal VM value 0xC JNS Jump if not signed 0xD JL Jump if less ( signed ) 0xE


EXEC Execute machine code and branch 0xF JBE Jump if below or equal or Jump if not above 0x10 SHL Shift left the internal value the number of times specified into the opcodes 0x11 JA Jump if above/Jump if not below or equal 0x12 MOV Move the internal VM value into a register 0x13 JZ JMP if zero 0x14 ADD Add an immediate value to the internal Vm descriptor 0x15 JB Jump if below ( unsigned ) 0x16 JS Jump if signed 0x17 EXEC Execute


machine code ( same as opcode 0x0 ) 0x18 JGE Jump if greater or equal/Jump if not less 0x19 DEREF Write a register value into a dereferenced pointer 0x1A JMP Special obfuscated “ Jump if below ” opcode 0x1B * Resolve a pointer 0x1C LOAD Load a value into the internal VM descriptor 0x1D JNE Jump if not equal/Jump if not zero 0x1E CALL Call an external function or a function located in the dropper 0x1F MOV


Move the value of a register into the VM descriptor 0x20 JNB Jump if not below/Jump if above or equal/Jump if not carry 0x21 JNP Jump if not parity/Jump if parity odd Each virtual instruction is stored in a special data structure that contains all the information needed to be properly read and executed by the VM .


This data structure is 24 bytes and is composed of some fixed fields and a variable portion that depends on the opcode .


Before interpreting the opcode , the VM decrypts the opcode ’ s content ( through a simple XOR algorithm ) , which it then relocates ( if needed ) , using the relocation fields .


Here is an approximate diagram of the opcode data structure : Figure 5 .


A graphical representation of the data structure used to store each VM opcode The VM handler is completely able to generate different code blocks and deal with relocated code due to address space layout randomization ( ASLR ) .


It is also able to move code execution into different locations if needed .


For instance , in the case of the “ Execute ” opcode ( 0x17 ) , the 32-bit code to run is stored entirely into the variable section with the value at offset 5 specifying the number of bytes to be copied and executed .


Otherwise , in the case of conditional opcodes , the variable part can contain the next JIT packet ID or the next relative virtual address ( RVA ) where code execution should continue .


Of course , not all the opcodes are can be easily read and understood due to additional steps that the authors have taken to make analysis extremely complicated .


For example , this is how opcode 0x1A is implemented : The opcode should represent a JB ( Jump if below ) function , but it ’ s implemented through set carry ( STC ) instruction followed by a JMP into the dispatcher code that will verify the carry flag condition set by STC .


Figure 6 .


One of the obfuscation tricks included by the malware authors in a VM opcode dispatcher Even armed with the knowledge we have described so far , it still took us many hours to write a full-fledged opcode interpreter that ’ s able to reconstruct the real code executed by FinFisher .


Stage 1 : Loader malware keeps sandbox and debuggers away The first stage of FinFisher running through this complicated virtual machine is a loader malware designed to probe the system and determine whether it ’ s running in a sandbox environment ( typical for cloud-based detonation solution like Office 365 ATP ) .


The loader first dynamically rebuilds a simple import address table ( IAT ) , resolving all the API needed from Kernel32 and NtDll libraries .


It then continues executing in a spawned new thread that checks if there are additional undesired modules inside its own virtual address space ( for example , modules injected by certain security solutions ) .


It eventually kills all threads that belong to these undesired modules ( using ZwQueryInformationThread native API with ThreadQuerySetWin32StartAddress information class ) .


The first anti-sandbox technique is the loader checking the code segment .


If it ’ s not 0x1B ( for 32-bit systems ) or 0x23 ( for 32-bit system under Wow64 ) , the loader exits .


Next , the dropper checks its own parent process for indications that it is running in a sandbox setup .


It calculates the MD5 hash of the lower-case process image name and terminates if one of the following conditions are met : The MD5 hash of the parent process image name is either D0C4DBFA1F3962AED583F6FCE666F8BC or 3CE30F5FED4C67053379518EACFCF879 The parent process ’ s full image path is equal to its own process path If these initial checks are passed , the loader builds a complete IAT by reading four imported libraries from disk ( ntdll.dll


, kernel32.dll , advapi32.dll , and version.dll ) and remapping them in memory .


This technique makes use of debuggers and software breakpoints useless .


During this stage , the loader may also call a certain API using native system calls , which is another way to bypass breakpoints on API and security solutions using hooks .


Figure 7 .


FinFisher loader calling native Windows API to perform anti-debugging tricks At this point , the fun in analysis is not over .


A lot of additional anti-sandbox checks are performed in this exact order : Check that the malware is not executed under the root folder of a drive Check that the malware file is readable from an external source Check that the hash of base path is not 3D6D62AF1A7C8053DBC8E110A530C679 Check that the full malware path contains only human readable characters ( “ a-z ” , “ A-Z ” , and “ 0-9 ” ) Check that no node in the full path contains the MD5 string of the malware


file Fingerprint the system and check the following registry values : HKLM\SOFTWARE\Microsoft\Cryptography\MachineGuid should not be “ 6ba1d002-21ed-4dbe-afb5-08cf8b81ca32 ” HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DigitalProductId should not be “ 55274-649-6478953-23109 ” , “ A22-00001 ” , or “ 47220 ” HARDWARE\Description\System\SystemBiosDate should not contain “ 01/02/03 ”


Check that the mutex WininetStartupMutex0 does not already exist Check that no DLL whose base name has hash value of 0xC9CEF3E4 is mapped into the malware address space The hashes in these checks are most likely correspond to sandbox or security products that the FinFisher authors want to avoid .


Next , the loader checks that it ’ s not running in a virtualized environment ( VMWare or Hyper-V ) or under a debugger .


For the hardware virtualization check , the loader obtains the hardware device list and checks if the MD5 of the vendor ID is equal to a predefined list .


In our tests , the malware sample was able to easily detect both VMWare and Hyper-V environments through the detection of the virtualized peripherals ( for example , Vmware has VEN_15AD as vendor ID , HyperV has VMBus as bus name ) .


Office 365 ATP sandbox employs special mechanisms to avoid being detected by similar checks .


The loader ’ s anti-debugger code is based on the following three methods : The first call aims to destroy the debugger connection : NOTE : This call completely stops the execution of WinDbg and other debuggers The second call tries to detect the presence of a debugger : The final call tries to destroy the possibility of adding software breakpoint : Finally , if the loader is happy with all the checks done so far , based on the victim operating system ( 32 or 64-bit ) it proceeds to decrypt a set of fake bitmap resources ( stage 2


) embedded in the executable and prepares the execution of a new layer of VM decoding .


Each bitmap resource is extracted , stripped of the first 0x428 bytes ( BMP headers and garbage data ) , and combined into one file .


The block is decrypted using a customized algorithm that uses a key derived from the original malware dropper ’ s TimeDateStamp field multiplied by 5 .


Figure 8 .


The fake bitmap image embedded as resource The 32-bit stage 2 malware uses a customized loading mechanism ( i.e. , the PE file has a scrambled IAT and relocation table ) and exports only one function .


For the 64-bit stage 2 malware , the code execution is transferred from the loader using a well-known technique called Heaven ’ s Gate .


In the next sections , for simplicity , we will continue the analysis only on the 64-bit payload .


Figure 9 .


Heaven ’ s gate is still in use in 2017 Stage 2 : A second multi-platform virtual machine The 64-bit stage 2 malware implements another loader combined with another virtual machine .


The architecture is quite similar to the one described previously , but the opcodes are slightly different .


After reversing these opcodes , we were able to update our interpreter script to support both 32-bit and 64-bit virtual machines used by FinFisher .


INDEX MNEMONIC DESCRIPTION 0x0 JMP Special obfuscated conditional Jump ( always taken or always ignored ) 0x1 JMP Jump to a function ( same as opcode 0x10 ) 0x2 CALL Call to the function pointed by the internal VM value 0x3 CALL Optimized CALL function ( like the 0x1E opcode of the 32-bit VM ) 0x4 EXEC Execute code and move to the next packet 0x5 JMP Jump to an internal function 0x6 NOP No operation , move to the


next packet 0x7 CALL Call an imported API ( whose address is stored in the internal VM value ) 0x8 LOAD Load a value into the VM descriptor structure * 0x9 STORE Store the internal VM value inside a register 0xA WRITE Resolve a pointer and store the value of a register in its content 0xB READ Move the value pointed by the VM internal value into a register 0xC LOAD Load a value into the VM descriptor structure ( not optimized ) 0xD CMP Compare the value pointed by the internal VM descriptor


with a register 0xE CMP Compare the value pointed by the internal VM descriptor with an immediate value 0xF XCHG Exchange the value pointed by the internal VM descriptor with a register 0x10 SHL Jump to a function ( same as opcode 0x1 ) This additional virtual machine performs the same duties as the one already described but in a 64-bit environment .


It extracts and decrypts the stage 3 malware , which is stored in encrypted resources such as fake dialog boxes .


The extraction method is the same , but the encryption algorithm ( also XOR ) is much simpler .


The new payload is decrypted , remapped , and executed in memory , and represents the installation and persistence stage of the malware .


Stage 3 : Installer that takes DLL side-loading to a new level Stage 3 represents the setup program for FinFisher .


It is the first plain stage that does not employ a VM or obfuscation .


The code supports two different installation methods : setup in a UAC-enforced environment ( with limited privileges ) , or an installation with full-administrative privileges enabled ( in cases where the malware gains the ability to run with elevated permissions ) .


We were a bit disappointed that we did not see traces of a true privilege escalation exploit after all this deobfuscation work , but it seems these FinFisher samples were designed to work just using UAC bypasses .


The setup code receives an installation command from the previous stage .


In our test , this command was the value 3 .


The malware creates a global event named 0x0A7F1FFAB12BB2 and drops some files under a folder located in C : \ProgramData or in the user application data folder .


The name of the folder and the malware configuration are read from a customized configuration file stored in the resource section of the setup program .


Here the list of the files potentially dropped during the installation stage : FILE NAME STAGE DESCRIPTION d3d9.dll Stage 4 Malware loader used for UAC environments with limited privileges ; also protected by VM obfuscation aepic.dll , sspisrv.dll , userenv.dll Stage 4 Malware loader used in presence of administrative privileges ; executed from ( and injected into ) a fake service ; also protected by VM obfuscation msvcr90.dll Stage 5 Malware payload injected into


the explorer.exe or winlogon.exe process ; also protected by VM obfuscation .cab Config Main configuration file ; encrypted setup.cab Unknown Last section of the setup executable ; content still unknown .7z Plugin Malware plugin used to spy the victim network communications wsecedit.rar Stage 6 Main malware executable After writing some of these files , the malware decides which kind of installation to perform based on the current privilege provided by the hosting process ( for example , if a Microsoft Office process was used as exploit vector ) : Installation process under


UAC When running under a limited UAC account , the installer extracts d3d9.dll and creates a persistence key under HKCU\Software\Microsoft\Windows\Run .


The malware sets a registry value ( whose name is read from the configuration file ) to “ C : \Windows\system32\rundll32.exe c : \ProgramData\AuditApp\d3d9.dll , Control_Run ” .


Before doing this , the malware makes a screenshot of the screen and displays it on top of all other windows for few seconds .


This indicates that the authors are trying to hide some messages showed by the system during the setup process .


When loaded with startup command 2 , the installer can copy the original explorer.exe file inside its current running directory and rename d3d9.dll to uxtheme.dll .


In this case the persistence is achieved by loading the original explorer.exe from its startup location and , using DLL side-loading , passing the execution control to the stage 4 malware ( discussed in next section ) .


Finally , the malware spawns a thread that has the goal to load , remap , and relocate the stage 5 malware .


In this context , there is indeed no need to execute the stage 4 malware .


The msvcr90.dll file is opened , read , and decrypted , and the code execution control is transferred to the RunDll exported routine .


In the case of 32-bit systems , the malware may attempt a known UAC bypass by launching printui.exe system process and using token manipulation with NtFilterToken as described in this blog post .


Installation process with administrative privilege This installation method is more interesting because it reveals how the malware tries to achieve stealthier persistence on the machine .


The method is a well-known trick used by penetration testers that was automated and generalized by FinFisher The procedure starts by enumerating the KnownDlls object directory and then scanning for section objects of the cached system DLLs .


Next , the malware enumerates all .exe programs in the % System % folder and looks for an original signed Windows binary that imports from at least one KnownDll and from a library that is not in the KnownDll directory .


When a suitable .exe file candidate is found , it is copied into the malware installation folder ( for example , C : \ProgramData ) .


At this point the malware extracts and decrypts a stub DLL from its own resources ( ID 101 ) .


It then calls a routine that adds a code section to a target module .


This section will contain a fake export table mimicking the same export table of the original system DLL chosen .


At the time of writing , the dropper supports aepic.dll , sspisrv.dll , ftllib.dll , and userenv.dll to host the malicious FinFisher payload .


Finally , a new Windows service is created with the service path pointing to the candidate .exe located in this new directory together with the freshly created , benign-looking DLL .


In this way , when the service runs during boot , the original Windows executable is executed from a different location and it will automatically load and map the malicious DLL inside its address space , instead of using the genuine system library .


This routine is a form of generic and variable generator of DLL side-loading combinations .


Figure 10 .


Windows Defender ATP timeline can pinpoint the service DLL side-loading trick ( in this example , using fltlib.dll ) .


In the past , we have seen other activity groups like LEAD employ a similar attacker technique named “ proxy-library ” to achieve persistence , but not with this professionalism .


The said technique brings the advantage of avoiding auto-start extensibility points ( ASEP ) scanners and programs that checks for binaries installed as service ( for the latter , the service chosen by FinFisher will show up as a clean Windows signed binary ) .


The malware cleans the system event logs using OpenEventLog/ClearEventLog APIs , and then terminates the setup procedure with a call to StartService to run the stage 4 malware .


Figure 11 .


The DLL side-loaded stage 4 malware mimicking a real export table to avoid detection Stage 4 : The memory loader – Fun injection with GDI function hijacking Depending on how stage 4 was launched , two different things may happen : In the low-integrity case ( under UAC ) the installer simply injects the stage 5 malware into the bogus explorer.exe process started earlier and terminates In the high-integrity case ( with administrative privileges or after UAC bypass ) , the code searches for the process hosting the Plug and Play service ( usually svchost.exe


) loaded in memory and injects itself into it For the second scenario , the injection process works like this : The malware opens the target service process .


It allocates and fills four chunks of memory inside the service process .


One chunk contains the entire malware DLL code ( without PE headers ) .


Another chunk is used to copy a basic Ntdll and Kernel32 import address table .


Two chunks are filled with an asynchronous procedure call ( APC ) routine code and a stub .


It opens the service thread of the service process and uses the ZwQueueApcThread native API to inject an APC .


The APC routine creates a thread in the context of the svchost.exe process that will map and execute the stage 5 malware into the winlogon.exe process .


The injection method used for winlogon.exe is also interesting and quite unusual .


We believe that this method is engineered to avoid trivial detection of process injection using the well-detected CreateRemoteThread or ZwQueueApcThread API .


The malware takes these steps : Check if the system master boot record ( MBR ) contains an infection marker ( 0xD289C989C089 8-bytes value at offset 0x2C ) , and , if so , terminate itself Check again if the process is attached to a debugger ( using the techniques described previously ) Read , decrypt , and map the stage 5 malware ( written in the previous stage in msvcr90.dll ) Open winlogon.exe process Load user32.dll system library and read the KernelCallbackTable


pointer from its own process environment block ( PEB ) ( Note : The KernelCallbackTable points to an array of graphic functions used by Win32 kernel subsystem module win32k.sys as call-back into user-mode .


) Calculate the difference between this pointer and the User32 base address .


Copy the stage 5 DLL into winlogon.exe Allocate a chunk of memory in winlogon.exe process and copy the same APC routine seen previously Read and save the original pointer of the __fnDWORD internal User32 routine ( located at offset +0x10 of the KernelCallbackTable ) and replace this pointer with the address of the APC stub routine After this function pointer hijacking , when winlogon.exe makes any graphical call ( GDI ) , the malicious code can execute without using CreateRemoteThread or


similar triggers that are easily detectable .


After execution it takes care of restoring the original KernelCallbackTable .


Stage 5 : The final loader takes control The stage 5 malware is needed only to provide one more layer of obfuscation , through the VM , of the final malware payload and to set up a special Structured Exception Hander routine , which is inserted as Wow64PrepareForException in Ntdll .


This special exception handler is needed to manage some memory buffers protection and special exceptions that are used to provide more stealthy execution .


After the VM code has checked again the user environment , it proceeds to extract and execute the final un-obfuscated payload sample directly into winlogon.exe ( alternatively , into explorer.exe ) process .


After the payload is extracted , decrypted , and mapped in the process memory , the malware calls the new DLL entry point , and then the RunDll exported function .


The latter implements the entire spyware program .


Stage 6 : The payload is a modular spyware framework for further analysis Our journey to deobfuscating FinFisher has allowed us to uncover the complex anti-analysis techniques used by this malware , as well as to use this intel to protect our customers , which is our top priority .


Analysis of the additional spyware modules is future work .


It is evident that the ultimate goal of this program is to steal information .


The malware architecture is modular , which means that it can execute plugins .


The plugins are stored in its resource section and can be protected by the same VM .


The sample we analyzed in October , for example , contains a plugin that is able to spy on internet connections , and can even divert some SSL connections and steal data from encrypted traffic .


Some FinFisher variants incorporate an MBR rootkit , the exact purpose of which is not clear .


Quite possibly , this routine targets older platforms like Windows 7 and machines not taking advantage of hardware protections like UEFI and SecureBoot , available on Windows 10 .


Describing this additional piece of code in detail is outside the scope of this analysis and may require a new dedicated blog post .


Defense against FinFisher Exposing as much of FinFisher ’ s riddles as possible during this painstaking analysis has allowed us to ensure our customers are protected against this advanced piece of malware .


Windows 10 S devices are naturally protected against FinFisher and other threats thanks to the strong code integrity policies that don ’ t allow unknown unsigned binaries to run ( thus stopping FinFisher ’ s PE installer ) or loaded ( blocking FinFisher ’ s DLL persistence ) .


On Windows 10 , similar code integrity policies can be configured using Windows Defender Application Control .


Office 365 Advanced Threat Protection secures mailboxes from email campaigns that use zero-day exploits to deliver threats like FinFisher .


Office 365 ATP blocks unsafe attachments , malicious links , and linked-to files using time-of-click protection .


Using intel from this research , we have made Office 365 ATP more resistant to FinFisher ’ s anti-sandbox checks .


Generic detections , advanced behavioral analytics , and machine learning technologies in Windows Defender Advanced Threat Protection detect FinFisher ’ s malicious behavior throughout the attack kill chain and alert SecOps personnel .


Windows Defender ATP also integrates with the Windows protection stack so that protections from Windows Defender AV and Windows Defender Exploit Guard are reported in Windows Defender ATP portal , enabling SecOps personnel to centrally manage security , and as well as promptly investigate and respond to hostile activity in the network .


We hope that this writeup of our journey through all the multiple layers of protection , obfuscation , and anti-analysis techniques of FinFisher will be useful to other researchers studying this malware .


We believe that an industry-wide collaboration and information-sharing is important in defending customers against this complex piece of malware .


TUESDAY , APRIL 9 , 2019 Gustuff banking botnet targets Australia EXECUTIVE SUMMARY Cisco Talos has uncovered a new Android-based campaign targeting Australian financial institutions .


As the investigation progressed , Talos came to understand that this campaign was associated with the " ChristinaMorrow '' text message spam scam previously spotted in Australia .


Although this malware 's credential-harvest mechanism is not particularly sophisticated , it does have an advanced self-preservation mechanism .


Even though this is not a traditional remote access tool ( RAT ) , this campaign seems to target mainly private users .


Aside from the credential stealing , this malware also includes features like the theft of users ' contact list , collecting phone numbers associated names , and files and photos on the device .


But that does n't mean companies and organizations are out of the woods .


They should still be on the lookout for these kinds of trojans , as the attackers could target corporate accounts that contain large amounts of money .


The information collected by the malware and the control over the victim 's mobile device allows their operators to perform more complex social engineering attacks .


A motivated attacker can use this trojan to harvest usernames and passwords and then reuse them to login into the organization 's system where the victim works .


This is a good example where two-factor authentication based on SMS would fail since the attacker can read the SMS .


Corporations can protect themselves from these side-channel attacks by deploying client-based two-factor authentication , such as Duo Security .


One of the most impressive features of this malware is its resilience .


If the command and control ( C2 ) server is taken down , the malicious operator can still recover the malware control by sending SMS messages directly to the infected devices .


This makes the taking down and recovery of the network much harder and poses a considerable challenge for defenders .


THE CAMPAIGN The malware 's primary infection vector is SMS .


Just like the old-school mail worms that used the victim 's address book to select the next victims , this banking trojan 's activation cycle includes the exfiltration of the victim 's address book .


The trojan will receive instructions from the C2 to spread .


Spread command from C2 The victim receives the command sendSMSMass .


Usually , this message targets four or five people at a time .


The body contains a message and URL .


Again , the concept is that new victims are more likely to install the malware if the SMS comes from someone they know .


When a victim tries to access the URL in the SMS body , the C2 will check if the mobile device meets the criteria to receive the malware ( see infrastructure section ) .


If the device does not meet the criteria , it wo n't receive any data , otherwise , it will be redirected to a second server to receive a copy of the malware to install on their device .


The domain on this campaign was registered on Jan. 19 , 2019 .


However , Talos has identified that was used at least since November 2018 .


During the investigation , Talos was also able to determine that the same infrastructure has been used to deploy similar campaigns using different versions of the malware .


Distribution of victims .


Talos assess with high confidence that this campaign is targeting Australian financial institutions based on several factors .


Our Umbrella telemetry shows that the majority of the request comes from Australia and the majority of the phone numbers infected have the international indicative for Australia .


Finally , the specific overlays are designed for Australian financial institutions , and Australia is one of the geographic regions that is accepted by the C2 .


DNS queries distribution over time The campaign does n't seem to be growing at a fast pace .


Our data shows , on average , about three requests per hour to the drop host .


This request is only made upon installation , but there is no guarantee that it will be installed .


This data , when analyzed with the number of commands to send SMSs that Talos received during the investigation , lead us to conclude that the malicious operator is aggressively spreading the malware , but that does n't seem to result in the same number of new infections .


Examples of the overlays available to the malware Above , you can see examples of the injections that distributed to the malware as part of this specific campaign .


While doing our investigation we were able to identify other malware packages with different names .


Some of these might have been used on old campaigns or were already prepared for new campaigns .


MALWARE TECHNICAL DETAILS During our investigation , researchers uncovered a malware known as " Gustuff. '' .


Given the lack of indicators of compromise , we decided to check to see if this was the same malware we had been researching .


Our Threat Intelligence and Interdiction team found the Gustuff malware being advertised in the Exploit.in forum as a botnet for rent .


The seller , known as " bestoffer , '' was , at some point , expelled from the forum .


Gustuff advertising screenshot The companies advertised in the image above were from Australia , which matches up with the campaign we researched .


The screenshots provided by the author align with the advertised features and the features that we discovered while doing our analysis .


Admin panel The administration panel shows the application configuration , which matches the commands from the C2 .


Country selection The administration console screenshots also show the ability to filter the results by country .


In this case , " AU '' is the code shown , which is Australia .


Based on this information , Talos assesses with high confidence that the malware is the same and this is , in fact , the Gustuff malware .


Design In the manifest , the malware requests a large number of permissions .


However , it does n't request permissions like BIND_ADMIN .


To perform some of its activities , the malware does not need high privileges inside the device , as we will explain ahead .


Permissions in the manifest This malware is designed to avoid detection and analysis .


It has several protections in place , both in the C2 and the malware 's code .


The code is not only obfuscated but also packed .


The packer , besides making the static analysis more complex , will break the standard debugger .


Manifest activity declaration Class list inside the dex file The main malware classes are packed , to a point where the class defined in the manifest has a handler for the MAIN category that does not exist in the DEX file .


Error when trying to debug the malware using the Android Studio IDE .


One of the side effects of this packer is the inability of Android Studio IDE to debug the code .


This happens because the IDE executes the code from the Android debug bridge ( ADB ) by calling the activity declared in the manifest by name .


Since the class does not exist at startup , the application does not run on the debugger .


Although Talos analyzed the unpacked version of the code , the packer analysis is beyond the scope of this post .


Check code for emulators As part of its defense , the malware payload first checks for emulators to prevent analysis on sandboxes .


It checks for different kinds of emulators , including QEMU , Genymotion , BlueStacks and Bignox .


If the malware determines that is not running on an emulator , it then performs additional checks to ensure that it wo n't be detected .


Code to check the existence of SafetyNet Google API It also checks if the Android SafetyNet is active and reporting back to the C2 .


This helps the C2 define what actions it can do before being detected on the mobile device .


List of anti-virus packages that are checked The payload goes a long way to protect itself and checks for anti-virus software installed on the mobile device .


The trojan uses the Android Accessibility API to intercept all interactions between the user and the mobile device .


The Android developer documentation describes the accessibility event class as a class that " represents accessibility events that are seen by the system when something notable happens in the user interface .


For example , when a button is clicked , a view is focused , etc .


'' For each interaction , the malware will check if the generator is a package that belongs to the anti-virus list , the malware will abuse another feature of the Accessibility API .


There is a function called " performGlobalAction '' with the description below .


Android documentation describes that function as " a global action .


Such an action can be performed at any moment , regardless of the current application or user location in that application .


For example , going back , going home , opening recents , etc .


'' The trojan calls this function with the action GLOBAL_ACTION_BACK , which equals the pressing of the back button on the device , thus canceling the opening of the anti-virus application .


The same event interception is used to place the webview overlay when the user tries to access the targeted applications , allowing it to display its overlay , thus intercepting the credentials .


The beaconing only starts after the application is installed and removed from the running tasks .


Beaconing information The ID is generated for each installation of the malware , while the token remains unique .


Some of the checks performed previously are immediately sent to the C2 , like the safetyNet , admin and defaultSMSApp .


The beaconing is sent to the URL http : // /api/v2/get.php with an interval of 60 seconds .


Answer from the C2 The C2 will check the country field , if it 's empty or if the country is not targeted , it will reply with a " Unauthorized '' answer .


Otherwise , it will return a JSON encoded " OK , '' and if that is the case , the command to be executed .


List of available commands The command names are self-explanatory .


The command will be issued as an answer to the beaconing , and the result will be returned to the URL http : // /api/v2/set_state.php Example of the command " changeServer '' The commands are issued in a JSON format , and the obfuscation is part of the malware code and not added by the packer .


It is a custom obfuscation partly based on base85 encoding , which is in itself unusual , in malware .


Base85 encoding is usually used on pdf and postscript documentsThe configuration of the malware is stored in custom preferences files , using the same obfuscation scheme .


Activation cycle As we have explained above , the malware has several defence mechanisms .


Beside the obfuscation and the environment checks , the malware also has some interesting anti-sandbox mechanisms .


After installation , the user needs to run the application .


The user needs to press the " close '' button to finish the installation .


However , this wo n't close the application , it will send it to the background , instead .


While the application is in the background , although the service is already running , the beaconing will not start .


The beaconing will only start after the application is removed from the background , ultimately stopping it .


This will be the trigger for the service to start the beaconing .


As mentioned previously , the beaconing is done every 60 seconds .


However , no command is received from the C2 until the inactiveTime field ( see beaconing information image above ) has at least the value of 2000000 .


This time resets every time the user performs some activity .


After the checks , the malware becomes active , but first , it goes through seven steps , each one calling a different command : uploadPhoneNumbers : Exfiltrates all phone numbers that are in the contact list .


Aside from the natural value of phone numbers associated with the names of their owners .


Using the SMS has an initial infection vector is another possibility for the exfiltration .


One of the purposes of the exfiltration of the contact list is to use them to attack other victims using SMS as an initial vector .


checkApps : Asks the malware to see if the packages sent as parameters are installed .


The malware contains a list of 209 packages hardcoded in its source code .


However , the C2 can send an updated list .


List of packages received from the C2 adminNumber : Setup of the admin phone number .


In our case , the administrator phone number belongs to a mobile network in Australia .


Phone number for administration changeServer : At this point , the malware changes the C2 to a new host , even though the API and communication protocol continues to be the same .


Change server request The URL 's for the new server is obfuscated , preventing easy network identification .


changeActivity : This command will set up the webview to overlay any of the target activities .


changeActivity command The webview injects are not hosted on the C2 , they are hosted on a completely different server .


params : This command allows the malicious operator to change configuration parameters in the malware .


During this stage of the activation cycle , the malware increases the beaconing time to avoid detection .


Command to change the beaconing changeArchive : The final command of the activation cycle is the download of an archive .


This archive is stored in the same host has the webviews .


The archive is a ZIP containing several files , which is protected with a password .


Change archive command After this activation cycle , the malware will start the collection of information activities and dissemination .


Malicious activity Once the activation cycle ends , the trojan will start its malicious activities .


These activities depend on the device configuration .


Depending if the victim has any of the targeted applications , the anti-virus installed or geographic location , the malware can harvest credentials from the targeted applications , exfiltrate all personal information or simply use the victim 's device to send SMS to spread the trojan The malware deploys overlaying webviews to trick the user and eventually steal their login credentials .


These are adapted to the information the malicious operator wants to retrieve .


The first webview overlay is created on step 6 of the activation cycle .


Pin request overlay This overlay asks the user to provide their PIN to unlock the mobile device , which is immediately exfiltrated to the C2 .


The last step of the activation cycle is the download of a password-protected ZIP file .


This file contains all HTML , CSS and PNG files necessary to create overlays .


Talos found 189 logos from banks to cryptocurrency exchanges inside the archive , all of which could be targeted .


The archive also contained all the necessary codes to target Australian financial institutions .


The overlays are activated by the malicious operator using the command changeActivity , as seen on step 5 of the activation cycle .


In this case , we can see that the HTML code of the overlay is stored in the C2 infrastructure .


However , since the archive that is downloaded into the device has all the necessary information and the malicious actor has access to the device via SMS , the malicious operator can keep its activity even without the C2 infrastructure .


Infrastructure The infrastructure supporting this malware is rather complex .


It is clear that on all stages there are at least two layers .


The infrastructure has several layers , although not being very dynamic , still has several layers each one providing some level of protection .


All the IP addresses belong to the same company Hetzner , an IP-hosting firm in Germany .


COVERAGE Cisco Cloud Web Security ( CWS ) or Web Security Appliance ( WSA ) web scanning prevents access to malicious websites and detects malware used in these attacks .


Email Security can block malicious emails sent by threat actors as part of their campaign .


Network Security appliances such as Next-Generation Firewall ( NGFW ) , Next-Generation Intrusion Prevention System ( NGIPS ) , and Meraki MX can detect malicious activity associated with this threat .


AMP Threat Grid helps identify malicious binaries and build protection into all Cisco Security products .


Umbrella , our secure internet gateway ( SIG ) , blocks users from connecting to malicious domains , IPs , and URLs , whether users are on or off the corporate network .


Open Source SNORTⓇ Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org .


INDICATORS OF COMPROMISE ( IOCS ) Domains Facebook-photos-au.su Homevideo2-12l.ml videohosting1-5j.gq URLs hxxp : //88.99.227 [ .


] 26/html2/2018/GrafKey/new-inj-135-3-dark.html hxxp : //88.99.227 [ .


] 26/html2/arc92/au483x.zip hxxp : //94.130.106 [ .


] 117:8080/api/v1/report/records.php hxxp : //88.99.227 [ .


] 26/html2/new-inj-135-3-white.html hxxp : //facebook-photos-au [ .


] su/ChristinaMorrow hxxp : //homevideo2-12l [ .


] ml/mms3/download_3.php IP addresses 78.46.201.36 88.99.170.84 88.99.227.26 94.130.106.117 88.99.174.200 88.99.189.31 Hash 369fcf48c1eb982088c22f86672add10cae967af82613bee6fb8a3669603dc48 b2d4fcf03c7a8bf135fbd3073bea450e2e6661ad8ef2ab2058a3c04f81fc3f3e


8f5d5d8419a4832d175a6028c9e7d445f1e99fdc12170db257df79831c69ae4e a5ebcdaf5fd10ec9de85d62e48cc97a4e08c699a7ebdeab0351b86ab1370557d 84578b9b2c3cc1c7bbfcf4038a6c76ae91dfc82eef5e4c6815627eaf6b4ae6f6


6bdfb79f813448b7f1b4f4dbe6a45d1938f3039c93ecf80318cedd1090f7e341 ADDITIONAL INFORMATION Packages monitored pin.secret.access com.chase.sig.android com.morganstanley.clientmobile.prod com.wf.wellsfargomobile com.citi.citimobile com.konylabs.capitalone com.infonow.bofa com.htsu.hsbcpersonalbanking com.usaa.mobile.android.usaa


com.schwab.mobile com.americanexpress.android.acctsvcs.us com.pnc.ecommerce.mobile com.regions.mobbanking com.clairmail.fth com.grppl.android.shell.BOS com.tdbank com.huntington.m com.citizensbank.androidapp com.usbank.mobilebanking com.ally.MobileBanking com.key.android com.unionbank.ecommerce.mobile.android com.mfoundry.mb.android.mb_BMOH071025661


com.bbt.cmol com.sovereign.santander com.mtb.mbanking.sc.retail.prod com.fi9293.godough com.commbank.netbank org.westpac.bank org.stgeorge.bank au.com.nab.mobile au.com.bankwest.mobile au.com.ingdirect.android org.banksa.bank com.anz.android com.anz.android.gomoney com.citibank.mobile.au org.bom.bank com.latuabancaperandroid


com.comarch.mobile com.jpm.sig.android com.konylabs.cbplpat by.belinvestbank no.apps.dnbnor com.arkea.phonegap com.alseda.bpssberbank com.belveb.belvebmobile com.finanteq.finance.ca pl.eurobank pl.eurobank2 pl.noblebank.mobile com.getingroup.mobilebanking hr.asseco.android.mtoken.getin pl.getinleasing.mobile com.icp.ikasa.getinon


eu.eleader.mobilebanking.pekao softax.pekao.powerpay softax.pekao.mpos dk.jyskebank.mobilbank com.starfinanz.smob.android.bwmobilbanking eu.newfrontier.iBanking.mobile.SOG.Retail com.accessbank.accessbankapp com.sbi.SBIFreedomPlus com.zenithBank.eazymoney net.cts.android.centralbank com.f1soft.nmbmobilebanking.activities.main com.lb.smartpay com.mbmobile


com.db.mobilebanking com.botw.mobilebanking com.fg.wallet com.sbi.SBISecure com.icsfs.safwa com.interswitchng.www com.dhanlaxmi.dhansmart.mtc com.icomvision.bsc.tbc hr.asseco.android.jimba.cecro com.vanso.gtbankapp com.fss.pnbpsp com.mfino.sterling cy.com.netinfo.netteller.boc ge.mobility.basisbank com.snapwork.IDBI


com.lcode.apgvb com.fact.jib mn.egolomt.bank com.pnbrewardz com.firstbank.firstmobile wit.android.bcpBankingApp.millenniumPL com.grppl.android.shell.halifax com.revolut.revolut de.commerzbanking.mobil uk.co.santander.santanderUK se.nordea.mobilebank com.snapwork.hdfc com.csam.icici.bank.imobile com.msf.kbank.mobile


com.bmm.mobilebankingapp net.bnpparibas.mescomptes fr.banquepopulaire.cyberplus com.caisseepargne.android.mobilebanking com.palatine.android.mobilebanking.prod com.ocito.cdn.activity.creditdunord com.fullsix.android.labanquepostale.accountaccess mobi.societegenerale.mobile.lappli com.db.businessline.cardapp com.skh.android.mbanking com.ifs.banking.fiid1491


de.dkb.portalapp pl.pkobp.ipkobiznes pl.com.suntech.mobileconnect eu.eleader.mobilebanking.pekao.firm pl.mbank pl.upaid.nfcwallet.mbank eu.eleader.mobilebanking.bre pl.asseco.mpromak.android.app.bre pl.asseco.mpromak.android.app.bre.hd pl.mbank.mnews eu.eleader.mobilebanking.raiffeisen pl.raiffeisen.nfc hr.asseco.android.jimba.rmb


com.advantage.RaiffeisenBank pl.bzwbk.ibiznes24 pl.bzwbk.bzwbk24 pl.bzwbk.mobile.tab.bzwbk24 com.comarch.mobile.investment com.android.vending com.snapchat.android jp.naver.line.android com.viber.voip com.gettaxi.android com.whatsapp com.tencent.mm com.skype.raider com.ubercab com.paypal.android.p2pmobile


com.circle.android com.coinbase.android com.walmart.android com.bestbuy.android com.ebay.gumtree.au com.ebay.mobile com.westernunion.android.mtapp com.moneybookers.skrillpayments com.gyft.android com.amazon.mShop.android.shopping com.comarch.mobile.banking.bgzbnpparibas.biznes pl.bnpbgzparibas.firmapp com.finanteq.finance.bgz pl.upaid.bgzbnpp


de.postbank.finanzassistent pl.bph de.comdirect.android com.starfinanz.smob.android.sfinanzstatus de.sdvrz.ihb.mobile.app pl.ing.mojeing com.ing.mobile pl.ing.ingksiegowosc com.comarch.security.mobilebanking com.comarch.mobile.investment.ing com.ingcb.mobile.cbportal de.buhl.finanzblick pl.pkobp.iko pl.ipko.mobile pl.inteligo.mobile de.number26.android


pl.millennium.corpApp eu.transfer24.app pl.aliorbank.aib pl.corelogic.mtoken alior.bankingapp.android com.ferratumbank.mobilebank com.swmind.vcc.android.bzwbk_mobile.app de.schildbach.wallet piuk.blockchain.android com.bitcoin.mwallet com.btcontract.wallet com.bitpay.wallet com.bitpay.copay btc.org.freewallet.app org.electrum.electrum


com.xapo com.airbitz com.kibou.bitcoin com.qcan.mobile.bitcoin.wallet me.cryptopay.android com.bitcoin.wallet lt.spectrofinance.spectrocoin.android.wallet com.kryptokit.jaxx com.wirex bcn.org.freewallet.app com.hashengineering.bitcoincash.wallet bcc.org.freewallet.app com.coinspace.app btg.org.freewallet.app net.bither


co.edgesecure.app com.arcbit.arcbit distributedlab.wallet de.schildbach.wallet_test com.aegiswallet com.plutus.wallet com.coincorner.app.crypt eth.org.freewallet.app secret.access secret.pattern RuMMS : The Latest Family of Android Malware Attacking Users in Russia Via SMS Phishing April 26 , 2016 Introduction Recently we observed an Android malware family being used to attack users in Russia .


The malware samples were mainly distributed through a series of malicious subdomains registered under a legitimate domain belonging to a well-known shared hosting service provider in Russia .


Because all the URLs used in this campaign have the form of hxxp : //yyyyyyyy [ .


] XXXX.ru/mms.apk ( where XXXX.ru represents the hosting provider ’ s domain ) , we named this malware family RuMMS .


To lure the victims to download the malware , threat actors use SMS phishing – sending a short SMS message containing a malicious URL to the potential victims .


Unwary users who click the seemingly innocuous link will have their device infected with RuMMS malware .


Figure 1 describes this infection process and the main behaviors of RuMMS .


On April 3 , 2016 , we still observed new RuMMS samples emerging in the wild .


The earliest identified sample , however , can be traced back to Jan. 18 , 2016 .


Within this time period , we identified close to 300 samples belonging to this family ( all sample hashes are listed in the Appendix ) .


After landing on the victim ’ s phone , the RuMMS apps will request device administrator privileges , remove their icons to hide themselves from users , and remain running in the background to perform a series of malicious behaviors .


So far we have identified the following behaviors : Sending device information to a remote command and control ( C2 ) server .


Contacting the C2 server for instructions .


Sending SMS messages to financial institutions to query account balances .


Uploading any incoming SMS messages ( including the balance inquiry results ) to the remote C2 server .


Sending C2-specified SMS messages to phone numbers in the victim ’ s contacts .


Forward incoming phone calls to intercept voice-based two-factor authentication .


Each of these behaviors is under the control of the remote C2 server .


In other words , the C2 server can specify the message contents to be sent , the time period in which to forward the voice call , and the recipients of outgoing messages .


As part of our investigation into this malware , we emulated an infected Android device in order to communicate with the RuMMS C2 server .


During one session , the C2 server commanded our emulated device to send four different SMS messages to four different phone numbers , all of which were associated with Russian financial institutions .


At least three of the messages were intended to check a user ’ s account balance at the institution ( we could not confirm the purpose of the fourth ) .Through additional research , we identified several forum posts where victims complained of funds ( up to 600 rubles ) were transferred out of their accounts after RuMMS infected their phones .


We do not know exactly how many people have been infected with RuMMS malware .


However , our data suggests that there have been at least 2,729 infections between January 2016 and early April 2016 , with a peak in March of more than 1,100 infections .


Smishing : The Major Way To Distribute RuMMS We have not observed any instances of RuMMS on Google Play or other online app stores .


Smishing ( SMS phishing ) is currently the primary way threat actors are distributing the malware .


The process starts when an SMS phishing message arrives at a user ’ s phone .


An example SMS message is shown in Figure 1 .


The message translates roughly to “ You got a photo in MMS format : hxxp : //yyyyyyyy.XXXX.ru/mms.apk. ” So far we identified seven different URLs being used to spread RuMMS in the wild .


All of the URLs reference the file “ mms.apk ” and all use the domain “ XXXX.ru ” , which belongs to a top five shared hosting platform in Russia ( the domain itself has been obfuscated to anonymize the provider ) .


The threat actors registered at least seven subdomains through the hosting provider , each consisting of eight random-looking characters ( asdfgjcr , cacama18 , cacamadf , konkonq2 , mmsmtsh5 , riveroer , and sdfkjhl2 .


) As of this writing , no files were hosted at any of the links .


The threat actors seem to have abandoned these URLs and might be looking into other ways to reach more victims .


Use of a shared hosting service to distribute malware is highly flexible and low cost for the threat actors .


It is also much harder for network defenders or researchers to track a campaign where the infrastructure is a moving target .


Many top providers in Russia offer cheap prices for their shared hosting services , and some even provide free 30-day trial periods .


Threat actors can register subdomains through the hosting provider and use the provider ’ s services for a short-period campaign .


A few days later they can cancel the trial and do not need to pay a penny .


In addition , these out-of-the-box hosting services usually provide better infrastructure than the attackers could manage to construct ( or compromise ) themselves .


RuMMS Code Analysis All RuMMS samples share the same behaviors , major parts of which are shown in Figure 1 .


However , the underlying code can be quite different in that various obfuscation mechanisms were adopted to evade detection by anti-virus tools .


We used a sample app named “ org.starsizew ” with an MD5 of d8caad151e07025fdbf5f3c26e3ceaff to analyze RuMMS ’ s code .


Several of the main components of RuMMS are shown in Figure 2 .


The activity class “ org.starsizew.MainActivity ” executes when the app is started .


It first starts another activity defined in “ org.starsizew.Aa ” to request device administrator privileges , and then calls the following API of “ android.content.pm.PackageManager ” ( the Android package manager to remove its own icon on the home screen in order to conceal the existence of RuMMS from the user : At the same time , ” org.starsizew.MainActivity ” will start the main service as defined in “ org.starsizew.Tb ” , and use a few mechanisms to keep the main service running continuously


in the background .


The class “ org.starsizew.Ac ” is designed for this purpose ; its only task is to check if the main service is running , and restart the main service if the answer is no .


The class “ org.starsizew.Tb ” also has a self-monitoring mechanism to restart itself when its own onDestroy API is triggered .


Other than that , its major functionality is to collect private device information , upload it to a remote C2 server , and handle any commands as requested by the C2 server .


All those functions are implemented in asynchronous tasks by “ org.starsizew.i ” .


The class “ org.starsizew.Ma ” is registered to intercept incoming SMS messages , the arrival of which will trigger the Android system to call its “ onReceive ” API .


Its major functionality is also implemented through the call of the asynchronous task ( “ org.starsizew.i ” ) , including uploading the incoming SMS messages to the remote C2 server and executing any commands as instructed by the remote attacker .


C2 Communication The C2 communication includes two parts : sending information to the remote HTTP server and parsing the server ’ s response to execute any commands as instructed by the remote attackers .


The functionality for these two parts is implemented by doInBackground and onPostExecute respectively , two API methods of “ android.os.AsyncTask ” as extended by class “ org.starsizew.i ” .


Figure 3 .


Method doInBackground : to send information to remote C2 server As seen from the major code body of method doInBackground shown in Figure 3 ( some of the original classes and methods are renamed for easier understanding ) , there are three calls to HttpPost with different contents as parameters .


At line 5 , local variable v4 specifies the first parameter url , which can be changed by the remote C2 server later .


These URLs are all in the form of “ http : // $ C2. $ SERVER. $ IP/api/ ?


id= $ NUM ” .


The second parameter is a constant string “ POST ” , and the third parameter is a series of key-value pairs to be sent , assembled at runtime .


The value of the first item , whose key is “ method ” ( line 7 ) , indicates the type of the contents : install , info and sms .


The first type of content , starting with “ method=install ” , will be sent when the app is started for the first time , including the following device private information : Victim identifier Network operator Device model Device OS version Phone number Device identifier App version Country The second type of information will be sent periodically to indicate that the device is alive .


It only has two parts , the method indicated by word “ info ” and the victim identifier .


The third type of information will be sent when RuMMS intercepts any SMS messages , including the balance inquiry results when it contacts the SMS code of a particular financial service .


Method onPostExecute parses the response from the above HTTP session and executes the commands provided by the remote attacker .


As seen from the code in Figure 5 , the commands RuMMS supports right now include : install_true : to modify app preference to indicate that the C2 server received the victim device ’ s status .


sms_send : to send C2-specified SMS messages to C2-specified recipients .


sms_grab : to upload periodically the SMS messages in the inbox to C2 server .


delivery : to deliver specified text to all victim ’ s contacts ( SMS worming ) .


call_number : to forward phone calls to intercept voice based two-factor authentication .


new_url : to change the URL of the C2 server in the app preference .


ussd : to call a C2-specified phone number .


Figure 5 .


Method onPostExecute : to handle instructions from remote C2 Figure 6 shows an example response sent back from one C2 server .


Note that inside this single response , there is one “ install_true ” command , one “ sms_grab ” command and four “ sms_send ” commands .


With the four “ sms_send ” commands , the messages as specified in the key “ text ” will be sent immediately to the specified short numbers .


Our analysis suggests that the four short numbers are associated with Russian financial institutions , presumably where a victim would be likely to have accounts .


Figure 6 .


Example Response in JSON format In particular , short number “ +7494 ” is associated with a payment service provider in Russia .


The provider ’ s website described how the code 7494 can be used to provide a series of payment-related capabilities .


For example , sending text “ Balance ” will trigger a response with the victim ’ s wallet balance .


Sending text “ confirm 1 ” will include proof of payment .


Sending text “ call on ” will activate the USSD payment confirmation service .


During our investigation , we observed the C2 server sending multiple “ balance ” commands to different institutions , presumably to query the victim ’ s financial account balances .


RuMMS can upload responses to the balance inquiries ( received via SMS message ) to the remote C2 server , which can send back additional commands to be sent from the victim to the provider ’ s payment service .


These could include resetting the user ’ s PIN , enabling or disabling various alerts and confirmations , and confirming the user ’ s identity .


RuMMS Samples , C2 , Hosting Sites , Infections and Timeline In total we captured 297 RuMMS samples , all of which attempt to contact an initial C2 server that we extracted from the app package .


Figure 7 lists the IP addresses of these C2 servers , the number of RuMMS apps that connect to each of them , and the example URL used as the first parameter of the HttpPost operation ( used in the code of Figure 3 ) .


This indicates that multiple C2 servers were used in this campaign , but one ( 37.1.207.31 ) was the most heavily used .


Figure 7 .


RuMMS samples and C2 servers Figure 8 shows how these samples , C2 servers and hosting websites are related to each other , including when they were compiled or observed .


In the quadrant , the smaller boxes in blue-gray represent particular apps in the RuMMS family , while the bigger boxes in deep-blue represent C2 servers used by some RuMMS apps .


The dotted arrows represent the use of a particular C2 server by a specific app to send information and fetch instructions .


In this figure we have 11 RuMMS samples , all of which were hosted on the website as shown in the “ y ” axis .


The dates on the “ x ” axis show the dates when we first saw these apps in the wild .


This figure demonstrates the following interesting information : The time range when threat actors distributed RuMMS on those shared-hosting websites is from January 2016 to March 2016 .


Threat actors used different websites to host different payloads at different times .


This kind of “ moving target ” behavior made it harder to track their actions .


The same websites have hosted different RuMMS samples at different dates .


C2 servers are shared by multiple samples .


This matches our observations of C2 servers as shown in Figure 7 .


Figure 8 .


RuMMS samples , hosting sites , C2 servers from Jan. 2016 to Mar .


2016 We do not know exactly how many people have been infected with RuMMS malware ; however , our data suggests that there are at least 2,729 infections with RuMMS samples from January 2016 to early April 2016 .


Figure 9 shows the number of RuMMS infections recorded in the last four months .


When we first observed the malware in January , we recorded 380 infections .


In February , we recorded 767 infections .


In March , it peaked at 1,169 infections .


In April , at the time of writing this post , we recorded 413 RuMMS infections .


Although the propagation trend seems to be slowing down a bit , the figure tells us that RuMMS malware is still alive in the wild .


We continue to monitor its progress .


Conclusion Smishing ( SMS phishing ) offers a unique vector to infect mobile users .


The recent RuMMS campaign shows that Smishing is still a popular means for threat actors to distribute their malware .


In addition , the use of shared-hosting providers adds flexibility to the threat actor ’ s campaign and makes it harder for defending parties to track these moving targets .


Fortunately , FireEye Mobile Threat Prevention platform can recognize the malicious SMS and networking behaviors used by these RuMMS samples , and help us quickly identify the threat .


To protect yourself from these threats , FireEye suggests that users : Take caution before clicking any links where you are not sure about the origin .


Don ’ t install apps outside the official app store .


Exodus : New Android Spyware Made in Italy Mar 29 Summary We identified a new Android spyware platform we named Exodus , which is composed of two stages we call Exodus One and Exodus Two .


We have collected numerous samples spanning from 2016 to early 2019 .


Instances of this spyware were found on the Google Play Store , disguised as service applications from mobile operators .


Both the Google Play Store pages and the decoys of the malicious apps are in Italian .


According to publicly available statistics , as well as confirmation from Google , most of these apps collected a few dozens installations each , with one case reaching over 350 .


All of the victims are located in Italy .


All of these Google Play Store pages have been taken down by Google .


We believe this spyware platform is developed by an Italian company called eSurv , which primarily operates in the business of video surveillance .


According to public records it appears that eSurv began to also develop intrusion software in 2016 .


Exodus is equipped with extensive collection and interception capabilities .


Worryingly , some of the modifications enforced by the spyware might expose the infected devices to further compromise or data tampering .


Disguised Spyware Uploaded on Google Play Store We identified previously unknown spyware apps being successfully uploaded on Google Play Store multiple times over the course of over two years .


These apps would remain available on the Play Store for months and would eventually be re-uploaded .


While details would vary , all of the identified copies of this spyware shared a similar disguise .


In most cases they would be crafted to appear as applications distributed by unspecified mobile operators in Italy .


Often the app description on the Play Store would reference some SMS messages the targets would supposedly receive leading them to the Play Store page .


All of the Play Store pages we identified and all of the decoys of the apps themselves are written in Italian .


According to Google , whom we have contacted to alert about our discoveries , nearly 25 variants of this spyware were uploaded on Google Play Store .


Google Play has removed the apps and they stated that " thanks to enhanced detection models , Google Play Protect will now be able to better detect future variants of these applications '' .


While Google did not share with us the total number of infected devices , they confirmed that one of these malicious apps collected over 350 installations through the Play Store , while other variants collected few dozens each , and that all infections were located in Italy .


We have directly observed multiple copies of Exodus with more than 50 installs and we can estimate the total number of infections to amount in the several hundreds , if not a thousand or more .


Stage 1 : Exodus One The first stage installed by downloading the malicious apps uploaded on Google Play Store only acts as a dropper .


Following are some examples of the decoys used by these droppers : The purpose of Exodus One seems to be to collect some basic identifying information about the device ( namely the IMEI code and the phone number ) and send it to the Command & Control server .


This is usually done in order to validate the target of a new infection .


This is further corroborated by some older and unobfuscated samples from 2016 , whose primary classes are named CheckValidTarget .


During our tests the spyware was upgraded to the second stage on our test device immediately after the first check-ins .


This suggests that the operators of the Command & Control are not enforcing a validation of the targets .


Additionally , during a period of several days , our infected test device was never remotely disinfected by the operators .


For the purpose of this report we analyze here the Exodus One sample with hash 8453ce501fee1ca8a321f16b09969c517f92a24b058ac5b54549eabd58bf1884 which communicated with the Command & Control server at 54.71.249.137 .


Other samples communicated with other servers listed at the bottom of this report .


Exodus One checks-in by sending a POST request containing the app package name , the device IMEI and an encrypted body containing additional device information .


The encrypted body is composed of various identifiers which are joined together : doFinal ( ) is called to encrypt the device information string : The user agent string is built from the package name and IMEI number : Finally the HTTP request is sent to the server at https : //54.71.249.137/eddd0317-2bdc-4140-86cb-0e8d7047b874 .


Many of the strings in the application are XOR 'd with the key Kjk1MmphFG : After some additional requests , the dropper made a POST request to https : //54.71.249.137/56e087c9-fc56-49bb-bbd0-4fafc4acd6e1 which returned a zip file containing the second stage binaries .


Stage 2 : Exodus Two The Zip archive returned by the check-in performed by Exodus One is a collection of files including the primary payload mike.jar and several compiled utilities that serve different functions .


At least in most recent versions , as of January 2019 , the Zip archive would actually contain the i686 , arm and arm64 versions of all deployed binaries .


File Name Modified Date SHA256 null_arm 2018-02-27 06:44:00 48a7dd672931e408662d2b5e1abcd6ef00097b8ffe3814f0d2799dd6fd74bd88 null_i686 2018-02-27 06:44:00 c228a534535b22a316a97908595a2d793d0fecabadc32846c6d1bfb08ca9a658 null_arm64 2018-02-27 06:43:00 48a7dd672931e408662d2b5e1abcd6ef00097b8ffe3814f0d2799dd6fd74bd88


sepolicy-inject_arm 2019-01-08 04:55:00 47449a612697ad99a6fbd6e02a84e957557371151f2b034a411ebb10496648c8 sepolicy-inject_arm64 2019-01-08 04:55:00 824ad333320cbb7873dc49e61c14f749b0e0d88723635524463f2e6f56ea133a sepolicy-inject_i686 2019-01-08 04:55:00 13ec6cec511297ac3137cf7d6e4a7c4f5dd2b24478a06262a44f13a3d61070b6


rootdaemon_arm 2019-01-08 04:55:00 00c787c0c0bc26caf623e66373a5aaa1b913b9caee1f34580bdfdd21954b7cc4 rootdaemon_arm64 2019-01-08 04:55:00 3ee3a973c62ba5bd9eab595a7c94b7a26827c5fa5b21964d511ab58903929ec5 mike.jar 2018-12-06 05:50:00 a42a05bf9b412cd84ea92b166d790e8e72f1d01764f93b05ace62237fbabe40e


rootdaemon_i686 2019-01-08 04:55:00 b46f282f9a1bce3798faee3212e28924730a657eb93cda3824c449868b6ee2e7 zygotedaemonarm 2019-01-08 04:55:00 e3f65f84dd6c2c3a5a653a3788d78920c0321526062a6b53daaf23fa57778a5f zygotedaemonarm64 2019-01-08 04:55:00 11499ff2418f4523344de81a447f6786fdba4982057d4114f64db929990b4b59


zygotedaemoni686 2019-01-08 04:55:00 3c9f08b3280851f54414dfa5a57f40d3b7be7b73736fa0ba21b078e75ce54d33 sapp.apk 2019-01-08 04:53:00 4bf1446c412dd5c552539490d03e999a6ceb96ae60a9e7846427612bec316619 placeholder 2018-03-29 16:31:00 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855


After download , Exodus One would dynamically load and execute the primary stage 2 payload mike.jar using the Android API DexClassLoader ( ) .


mike.jar implements most of the data collection and exfiltration capabilities of this spyware .


Of the various binaries downloaded , the most interesting are null , which serves as a local and reverse shell , and rootdaemon , which takes care of privilege escalation and data acquisition .


rootdaemon will first attempt to jailbreak the device using a modified version of the DirtyCow exploit .


Similarly to another Android spyware made in Italy , originally discovered by Lukas Stefanko and later named Skygofree and analyzed in depth by Kaspersky Labs , Exodus also takes advantage of " protectedapps '' , a feature in Huawei phones that allows to configure power-saving options for running applications .


By manipulating a SQLite database , Exodus is able to keep itself running even when the screen goes off and the application would otherwise be suspended to reduce battery consumption .


Additionally , rootdaemon attempts to remove its own power usage statistics from Huawei phones ' SystemManager : Similarly , the malicious application probably attempts to minimize traces on Samsung phones by adding to the file /data/data/com.samsung.android.securitylogagent/shared_prefs/apm_sp_status_of_apps.xml the following lines : And adding to the file /data/data/com.samsung.android.securitylogagent/shared_prefs/com.samsung.android.securitylogagent_preferences.xml


these lines instead : Data Collection and Exfiltration As mentioned , mike.jar equips the spyware with extensive collection capabilities , including : Retrieve a list of installed applications .


Record surroundings using the built-in microphone in 3gp format .


Retrieve the browsing history and bookmarks from Chrome and SBrowser ( the browser shipped with Samsung phones ) .


Extract events from the Calendar app .


Extract the calls log .


Record phone calls audio in 3gp format .


Take pictures with the embedded camera .


Collect information on surrounding cellular towers ( BTS ) .


Extract the address book .


Extract the contacts list from the Facebook app .


Extract logs from Facebook Messenger conversations .


Take a screenshot of any app in foreground .


Extract information on pictures from the Gallery .


Extract information from th GMail app .


Dump data from the IMO messenger app .


Extract call logs , contacts and messages from the Skype app .


Retrieve all SMS messages .


Extract messages and the encryption key from the Telegram app .


Dump data from the Viber messenger app .


Extract logs from WhatsApp .


Retrieve media exchanged through WhatsApp .


Extract the Wi-Fi network 's password .


Extract data from WeChat app .


Extract current GPS coordinates of the phone .


While some of these acquisition are performed purely through code in mike.jar , some others that require access to , for example , SQLite databases or other files in the application 's storage are performed through rootdaemon instead , which should be running with root privileges .


In order to achieve this , mike.jar connects to rootdaemon through various TCP ports that the daemon binds on some extraction routines for supported applications : Port 6202 : WhatsApp extraction service .


Ports 6203 and 6204 : Facebook extraction service .


Port 6205 : Gmail extraction service .


Port 6206 : Skype extraction service .


Port 6207 : Viber extraction service .


Port 6208 : IMO extraction service .


Port 6209 : Telegram extraction service .


Port 6210 : SBrowser extraction service .


Port 6211 : Calendar extraction service .


Port 6212 : Chrome extraction service .


These services appear to be running on all network interfaces and are therefore accessible to anyone sharing a local network with an infected device .


Following we can see an example of a connection to port 6209 which is used to extract data from the Telegram app .


We are able to send commands to the service such as dumpmsgdb or getkey ( which dumps the tgnet.dat file ) .


Data acquired from mike.jar 's extraction modules is normally XORed and stored in a folder named .lost+found on the SD card .


Data is eventually exfiltrated over a TLS connection to the Command & Control server ws.my-local-weather [ .


] com through an upload queue .


As mentioned before , our test device was automatically from stage one to stage two , which started collecting data .


For example , the password of the WiFi network used by the phone was stored in the folder /storage/emulated/0/.lost+found/0BBDA068-9D27-4B55-B226-299FCF2B4242/ using the following file name format DD_MM_2019_HH_mm_ss_XXXXXXXXXXXXX.txt.crypt ( the datetime followed by the IMEI ) .


Eventually we observed the agent exfiltrate the WiFi password from our test phone to the Command & Control server : Similarly , the agent also sent to the Command & Control the list of installed apps : This Command & Control seems to have been active since at least April 2017 and was registered impersonating the legitimate service AccuWeather .


Local and Remote Shells In order to execute commands on the infected devices , as well as to provide a reverse shell to the Command & Control operators , Exodus Two immediately attempts to execute a payload it downloads with the name null .


Once launched , null will first verify whether it is able to fork on the system and that there is no other instance of itself currently running by checking whether the local port number 6842 is available .


This payload will then attempt to instantiate a remote reverse /system/bin/sh shell to the Command & Control ws.my-local-weather [ .


] com on port 22011 .


It is worth noticing that this remote reverse shell does not employ any transport cryptography .


The traffic transits in clear and is therefore potentially exposed to man-in-the-middle attacks : At the same time , null will also bind a local shell on 0.0.0.0:6842 .


This local port is used by Exodus Two to execute various commands on the Android device , such as enabling or disabling certain services , or parsing app databases .


However , binding a shell on all available interfaces will obviously make it accessible to anyone who is sharing at least a local network with an infected device .


For example , if an infected device is connected to a public Wi-Fi network any other host will be able to obtain a terminal on the device without any form of authentication or verification by simply connecting to the port .


If the mobile operator does n't enforce proper client isolation , it is possible that the infected devices are also exposed to the rest of the cellular network .


Obviously , this inevitably leaves the device open not only to further compromise but to data tampering as well .


null is not the only payload opening a shell on the phone .


The rootdaemon binary in fact offers several other possibilities to execute commands on the infected device just by connecting to TCP port 6200 and issuing one of the following commands .


Sending the command sh to TCP port 6200 results in a full terminal being dropped : Sending the command cmd followed by a proper terminal command will execute it and print the output ( in the example we use id which displays the identity of the system user running the issued commands ) : Doing the same as above but with command sucmd will run the terminal command as root : Other commands supported by rootdaemon on TCP port 6200 are su ( which in our tests did n't properly work ) , loadsocketpolicy , loadfilepolicy , remount and removeroot


At the cost of possibly being overly verbose , following is the output of an nmap scan of the infected Android device from a laptop in the same local network , which further demonstrantes the availability of the same open TCP ports that we have mentioned thus far : Identification of eSurv Presence of Italian language At a first look , the first samples of the spyware we obtained did not show immediately evident connections to any company .


However , the persistent presence of Italian language both on the Google Play Store pages as well as inside the spyware code was a clear sign that an Italian actor was behind the creation of this platform .


Initially some particular words from the decompiled classes.dex of Exodus Two sent us in the right direction .


" Mundizza '' is a dialectal word , a derivative of the proper Italian word " immondizia '' that translates to " trash '' or " garbage '' in English .


Interestingly , " mundizza '' is typical of Calabria , a region in the south of Italy , and more specifically it appears to be language native of the city of Catanzaro .


Additionally , some copies of Exodus One use the following XOR key : Rino Gattuso is a famous retired Italian footballer , originally from Calabria .


While not too seriously , these elements made us restrict our research into surveillance companies from the region .


Overlapping Infrastructure with eSurv Surveillance Cameras The Command & Control domain configured in several of the malicious applications found on Google Play Store , ws.my-local-weather [ .


] com , points to the IP address 54.69.156.31 which serves a self-signed TLS certificate with the certificate common name MyCert and fingerprint 11:41:45:2F : A7:07:23:54 : AE:9A : CE : F4 : FE:56 : AE : AC : B1 : C2:15:9F:6A : FC:1E : CC:7D : F8:61 : E3:25:26:73:6A .


A search for this certificate fingerprint on the Internet scanning service Censys returns 8 additional servers : IP address 34.208.71.9 34.212.92.0 34.216.43.114 52.34.144.229 54.69.156.31 54.71.249.137 54.189.5.198 78.5.0.195 207.180.245.74 Opening the Command & Control web page in a browser presents a Basic Authentication prompt : Closing this prompt causes the server to send a " 401 Unauthorized Response '' with an " Access Denied '' message in Italian


All of the other IP address we discovered sharing the same TLS certificate behave in the same way .


The Command & Control server also displays a favicon image which looks like a small orange ball .


At the time of writing , a reverse image search for the favicon on Shodan using the query http.favicon.hash:990643579 returned around 40 web servers which use the same favicon .


Many of these servers are control panels for video surveillance systems developed by the Italian company eSurv , based in Catanzaro , in Calabria , Italy .


Their publicly advertised products include CCTV management systems , surveillance drones , face and license plate recognition systems .


eSurv 's logo is identical to the Command & Control server favicon .


Older samples connecting to eSurv Finally , Google shared with us some older samples of Exodus One ( with hashes 2055584625d24687bd027a63bc0b8faa7d1a854a535de74afba24840a52b1d2f and a37f5d2418c5f2f64d06ba28fe62edee1293a56158ddfa9f04020e316054363f ) which are not obfuscated and use the following disguise : The configuration of these older samples


is very similar to newer ones , but it provides additional insights being not obfuscated : Firstly we can notice that , instead of generic domain names or IP addresses , these samples communicated with a Command & Control server located at attiva.exodus.esurv [ .


] it ( " attiva '' is the Italian for " activate '' ) .


( We named the spyware " Exodus '' after this Command & Control domain name .


) Following is the snippet of code in these older Exodus One samples showing the connection to the Command & Control : Below is the almost identical composition of the request to the Command & Control server in mike.jar ( also containing the path 7e661733-e332-429a-a7e2-23649f27690f ) : To further corroborate the connection of the Exodus spyware with eSurv , the domain attiva.exodus.esurv.it resolves to the IP 212.47.242.236 which , according to


public passive DNS data , in 2017 was used to host the domain server1cs.exodus.connexxa.it .


Connexxa was a company also from Catanzaro .


According to publicly available information , the founder of Connexxa seems to also be the CEO of eSurv .


Interestingly , we found other DNS records mostly from 2017 that follow a similar pattern and appear to contain two-letters codes for districts in Italy : Server City server1bo.exodus.connexxa [ .


] it Bologna server1bs.exodus.connexxa [ .


] it Brescia server1cs.exodus.connexxa [ .


] it Cosenza server1ct.exodus.connexxa [ .


] it Catania server1fermo.exodus.connexxa [ .


] it server1fi.exodus.connexxa [ .


] it Firenze server1gioiat.exodus.connexxa [ .


] it server1na.exodus.connexxa [ .


] it Napoli server1rc.exodus.connexxa [ .


] it Reggio Calabria server2ct.exodus.connexxa [ .


] it Catania server2cz.exodus.connexxa [ .


] it Catanzaro server2fi.exodus.connexxa [ .


] it Firenze server2mi.exodus.connexxa [ .


] it Milano server2rc.exodus.connexxa [ .


] it Reggio Calabria server3bo.exodus.connexxa [ .


] it Bologna server3ct.exodus.connexxa [ .


] it Catania server3.exodus.connexxa [ .


] it server3fi.exodus.connexxa [ .


] it Firenze server4fi.exodus.connexxa [ .


] it Firenze serverrt.exodus.connexxa [ .


] it Public Resume Confirms Development of Android Agent Additionally , an employee of eSurv quite precisely described their work in developing an " agent to gather data from Android devices and send it to a C & C server '' as well as researching " vulnerabilities in mobile devices ( mainly Android ) '' in a publicly available resume .


Further details in it reflect characteristics of Exodus ( such as the bypass of power managers we described from Exodus One , and more ) : Indicators of Compromise Exodus One 011b6bcebd543d4eb227e840f04e188fb01f2335b0b81684b60e6b45388d3820 0f5f1409b1ebbee4aa837d20479732e11399d37f05b47b5359dc53a4001314e5 2055584625d24687bd027a63bc0b8faa7d1a854a535de74afba24840a52b1d2f


a37f5d2418c5f2f64d06ba28fe62edee1293a56158ddfa9f04020e316054363f db59407f72666526fca23d31e3b4c5df86f25eff178e17221219216c6975c63f e0acbb0d7e55fb67e550a6bf5cf5c499a9960eaf5f037b785f9004585202593b Exodus One Package Names com.phonecarrier.linecheck


rm.rf operatore.italia it.offertetelefonicheperte it.servizipremium assistenza.sim assistenza.linea.riattiva assistenza.linea it.promofferte Exodus Two 64c11fdb317d6b7c9930e639f55863df592f23f3c7c861ddd97048891a90c64b a42a05bf9b412cd84ea92b166d790e8e72f1d01764f93b05ace62237fbabe40e Exodus Two


ELF Utilities 00c787c0c0bc26caf623e66373a5aaa1b913b9caee1f34580bdfdd21954b7cc4 11499ff2418f4523344de81a447f6786fdba4982057d4114f64db929990b4b59 13ec6cec511297ac3137cf7d6e4a7c4f5dd2b24478a06262a44f13a3d61070b6 3c9f08b3280851f54414dfa5a57f40d3b7be7b73736fa0ba21b078e75ce54d33


Command & Controls ad1.fbsba [ .


] com ws.my-local-weather [ .


] com 54.71.249 [ .


] 137 54.69.156 [ .


] 31 162.243.172 [ .


] 208 attiva.exodus.esurv [ .


] it The rise of mobile banker Asacub 28 AUG 2018 We encountered the Trojan-Banker.AndroidOS.Asacub family for the first time in 2015 , when the first versions of the malware were detected , analyzed , and found to be more adept at spying than stealing funds .


The Trojan has evolved since then , aided by a large-scale distribution campaign by its creators ( in spring-summer 2017 ) , helping Asacub to claim top spots in last year ’ s ranking by number of attacks among mobile banking Trojans , outperforming other families such as Svpeng and Faketoken .


We decided to take a peek under the hood of a modern member of the Asacub family .


Our eyes fell on the latest version of the Trojan , which is designed to steal money from owners of Android devices connected to the mobile banking service of one of Russia ’ s largest banks .


Asacub versions Sewn into the body of the Trojan is the version number , consisting of two or three digits separated by periods .


The numbering seems to have started anew after the version 9 .


The name Asacub appeared with version 4 in late 2015 ; previous versions were known as Trojan-SMS.AndroidOS.Smaps .


Versions 5.X.X-8.X.X were active in 2016 , and versions 9.X.X-1.X.X in 2017 .


In 2018 , the most actively distributed versions were 5.0.0 and 5.0.3 .


Communication with C & C Although Asacub ’ s capabilities gradually evolved , its network behavior and method of communication with the command-and-control ( C & C ) server changed little .


This strongly suggested that the banking Trojans , despite differing in terms of capability , belong to the same family .


Data was always sent to the C & C server via HTTP in the body of a POST request in encrypted form to the relative address /something/index.php .


In earlier versions , the something part of the relative path was a partially intelligible , yet random mix of words and short combinations of letters and numbers separated by an underscore , for example , “ bee_bomb ” or “ my_te2_mms ” .


Example of traffic from an early version of Asacub ( 2015 ) The data transmitted and received is encrypted with the RC4 algorithm and encoded using the base64 standard .


The C & C address and the encryption key ( one for different modifications in versions 4.x and 5.x , and distinct for different C & Cs in later versions ) are stitched into the body of the Trojan .


In early versions of Asacub , .com , .biz , .info , .in , .pw were used as top-level domains .