Sonicwall Capture Labs Threat Research team has observed many Android locker ransomware which asks to communicate using social media platforms. There is no assurance of getting the key even after paying the ransom amount, they just use these apps for monetary gain. Some of the applications look like free social media follower apps but are ransomware as shown below.

 

Figure 1: Ransomware App Icons

 

All these malicious apps are recently submitted over malware sharing platforms like Virus Total.

 

Figure 2: VirusTotal submission history

 

Infection Cycle:

Major permissions used in these apps are mentioned below:

• SYSTEM_ALERT_WINDOW
• RECEIVE_BOOT_COMPLETED
• SET_WALLPAPER
• READ_EXTERNAL_STORAGE
• WRITE_EXTERNAL_STORAGE
• READ_CONTACTS
• READ_SMS
• ACCESS_FINE_LOCATION
• WAKE_LOCK
• INTERNET
• REQUEST_INSTALL_PACKAGE
• CAMERA

Permission “SYSTEM_ALERT_WINDOW“  is used to display overlay windows above all activity windows in order to show ransom notes.

After installation app is not visible on the app drawer, to view installed app information we need to go into settings->Apps

 

Figure 3: Malicious app visible under settings

 

In the manifest file, “android.intent.category.LAUNCHER” is not set in MainActivity as shown below, which means that this application does not have a desktop startup icon.

 

Figure 4: Main activity launcher missing

 

Malicious application launches after “ACTION_BOOT_COMPLETED” system event which is fired once the Android system has completed the boot process, sets a lock screen with a ransom note and the user is not able to access the device.

 

Figure 5: Ransom note

 

On further investigation of malicious code, each malicious file has a different ransom note and different keys which are present in code itself under “password” field. No actual encryption of any file present on the device takes place except by locking the screen.

 

Figure 6: Password and Ransom note present in code

 

SonicWall Capture Labs provides protection against this threat via the SonicWall Capture ATP w/RTDMI.

Indicators of Compromise (IOC):

11a11a11a266f9d3858d1b52aca73b701406cbc587bf52a5256c20452d574d0a

193c8bc1f44cf310e670c0a4a9e19f9ad35afaac63eb549f9cc8dafa240555af

2cd6920661eec231b66ac3601ca380ba846490c8f535b903d3844326084ac490

2da6a8f85888d39c3a45b6d6367492e67243e985ef8bc4dc441fd66ffcbe3d9c

ac70993fb26bd4590d3656a4b6ba1e0787a9c524ed5ed5592663a6d8c05c32a1

ec38798940dbab431f3dacab74267b143e206ed8e3fc406be90125825198576a

A good thief steals without leaving any footprint behind, the similar job is done by file less malware in the threat world.  Additionally if a file less malware getting the work done without involving Potable Executable (PE) file, not even in the memory is like ‘icing on the cake’. GuLoader is a file less shellcode based malware, recently observed by SonicWall threat research team.  A VBS script inside an archive file is delivered to the victim’s machine as an email attachment which loads GuLoader shellcode into PowerShell executable. GuLoader further downloads and executes other malware in the  memory of a legitimate process:

Infection Cycle:

VBSCRIPT

The obfuscated VBScript contains code broken into variables which is concatenated on execution. The VBScript stores the shellcode into registry entry HKEY_CURRENT_USER\Software\Fordyred6 which varies across the variants. A PowerShell script is then executed to read the registry value and continue the infection process:

PowerShell Script

The PowerShell script allocates memory into powershell.exe using API ZwAllocateVirtualMemory and reads the shellcode data from the registry entry. The shellcode is copied into allocated memory using RtlMoveMemory and executed inside powershell.exe:

Shellcode

An error window saying “This program cannot be run under virtual environment or debugging software!” can be seen on execution of the shellcode in a controlled environment. While analyzing the shellcode, a malware researcher should be habitual of seeing this window again and again, because the shellcode is full of anti debug and anti VM techniques:

 

Initial 0x41 bytes of the shellcode works as decryptor bytes for the remaining shellcode. The decryption is done using a XOR operation with a constant value:

 

After decrypting the remaining shellcode, the decryptor code ( initial 0x41 bytes) are replaced with 0x90 (NOP instruction) and control is transferred to the decrypted shellcode:

 

The shellcode uses PEB traversal method to get the API addresses by comparing API names with its own list of hashes. The malware uses custom DJB2 hashing algorithm to avoid detection from various security software. If custom DJB2 algorithm is not used, DJB2 hashes of the various APIs would be same across the malware variants which makes the detection pretty easy for the security software:

 

 

The malware involves various anti debug and anti VM techniques. It keeps all the strings encrypted which are decrypted and used on demand basis. It encrypts the code before calling the API and decrypts it back after calling the API.

Strings Decryption

The malware keeps the string encrypted which are being decrypted just before using them. The malware keeps a DWORD value before encrypted string, which is XOR with a constant value to get the string size. The malware contains a decryption key of size 0x2B bytes which is used to decrypt the encrypted strings using XOR operation:

Anti API Hook

The malware traverses the ntdll.dll memory starting from the code section and looks for bytes [0xb8, 0x00, ??, ??, 0xBA] to get the code responsible for making the system calls. These system calls are hooked by many security software to change the control flow to the their code for investigating the API calls. If the system calls code is patched, the malware restores them back to the original bytes:

Anti Dump

The malware encrypts the shellcode just before calling any API, to prevent event based memory dumps or analysis. After the API is called shellcode is decrypted back:

 

Anti Debug

 

Software Breakpoints

The malware checks for software breakpoints before calling the API by comparing initial bytes of the API with 0xCC (INT3) and initial word with 0x03CD (INT 3) and 0x0B0F (UD2). If any of these breakpoint instructions is found, the malware shows the error window message mentioned in the beginning and terminates the execution:

 

Vectored Exception Handler

The malware registers vectored exception handler with malware defined callback module which checks for INT3 (0xCC) exception and computes the next Extended Instruction Pointer (EIP) address by XOR the next byte of current EIP, to continue after the exception. The INT3 instruction is handled by the debugger which misleads the control flow to incorrect execution path:

 

However adding this vectored exception handler is an anti debugging technique, moreover in this malware this can be named as irritating technique for a researchers, because the code is full of INT3 instructions along with opaque predicate and arithmetic calculations. The researcher needs to either bypass the instruction by calculating the next EIP which will make him tired, or he needs to write a plugin code to bypass the instruction, which is again time consuming:

 

KUSER_SHARED_DATA

Similar to user mode GetTickCount API, kernel mode ZwGetTickCount reads values from the KUSER_SHARED_DATA page. This page is mapped read-only into the user mode at address 0x7FFE0000. The malware reads the values directly from KUSER_SHARED_DATA before and after executing some instructions and calculates the difference. The difference is calculated multiple times and added to a variable which is compared to the threshold value to check for debugging environment. If the computed value does not meet the threshold condition it will continue the execution in a infinite loop:

 

DbgBreakPoint

The malware modified the memory protection to ntdll.dll to  PAGE_EXECUTE_READWRITE  using ZwProtectVirtualMemory API and replaces INT3 instruction with NOP instruction inside DbgBreakPoint API to disallow attaching debugger:

 

DbgUiRemoteBreakin

The malware replaces code inside DbgUiRemoteBreakin to invoke ExitProcess API with exit code 0:

 

ThreadHideFromDebugger

The malware invokes ZwSetInformationThread API by setting ThreadInformationClass argument as ThreadHideFromDebugger which detaches the debugger and terminates the process immediately, if running under a debugger:

 

Anti VM

The malware gets the virtual memory using API ZwQueryVirtualMemory and searches for string “vmtoolsdControlWndClass” and if finds the string, the malware considers the execution in controlled environment. If malware finds any evidence of running under virtual environment, it shows the error message window and terminates the execution:

 

CPUID

The malware executes the CPUID instruction with EAX = 1 (to get processor features) as input and examines result value in ECX register. If the 31st bit is of the ECX register is set, the malware considers the execution inside the Virtual Machine (VM):

QEMU Emulator

The malware checks for the presence of files related to QEMU emulator:

• C:\Program Files\Qemu-ga\qemu-ga.exe
• C:\Program Files\qga\qga.exe

Enumerate Windows

The malware enumerates windows using EnumWindows API and checks the windows count, if count is less then 0xC then the malware considers the execution in controlled environment:

 

Enumerate Device Drivers

The malware retrieves load addresses of the device drivers using API EnumDeviceDrivers and gets the name associates with each load address using API  GetDeviceDriverBaseNameA . The malware computes custom DJB2 hash value of device driver names and compares them with its list of hashes:

• D82B79F9
• 72FCC347
• 55C69E11 (vmmouse.sys)
• 6538B8EE (vmusbmouse.sys)
• 907D9998
• 83277DEB (vm3dmp.sys)

 

Enumerate Installed Software

The malware enumerates installed products using MsiEnumProductsA API and retrieves the product name using API MsiGetProductInfoA. The malware computes custom DJB2 hash value of product names and compares them with its list of hashes:

• 30565F59
• E5AB7D36
• 4F3EA1F6
• 27D195CB

 

Enumerate Services

The malware opens specified service control manager database using API OpenSCManagerA and retrieves the service names using API EnumServicesStatusA. The malware computes custom DJB2 hash value of service names and compares them with its list of hashes:

• C99647C9
• ACBC4B26 (VMware Tools)
• F1D665FC (VMware Snapshot Provider)
• 82D0D13B
• 1605A96C
• CE8609AB
• 9D86D771

 

Debug Port

The malware invokes API ZwQueryInformationProcess with parameters ProcessInformationClass as ProcessDebugPort. If the API call succeeded, the malware considers the execution under the debugger:

 

Code Injection

The malware creates process “C:\Windows\Microsoft.NET\Framework\v2.0.50727\caspol.exe” in CREATE_SUSPENDED mode. The malware creates a section and tries to map the section into the suspended process at 0x400000 but it failed with 0x40000003 (STATUS_IMAGE_NOT_AT_BASE). The malware allocates virtual memory into the suspended process using API ZwAllocateVirtualMemory.

 

The malware writes the shellcode bytes (0x8D000) into the suspended process using API ZwWriteVirtualMemory:

 

The malware modifies the EIP of the suspended process from its entrypoint to the injected shellcode using API ZwSetContextThread:

 

The malware resumes the suspended process using API ZwResumeThread. The shellcode again starts from the beginning but in the context of a new process. The shellcode again executes all the anti debug and anti VM techniques but this time additionally it also downloads the payload data:

 

The malware downloads encrypted payload from URL h[t][t]ps://onedrive.live.com/download?cid=5E3278A18A104B1A&resid=5E3278A18A104B1A%21117&authkey=ABLIkl0zjTxzpTk by setting user agent as “Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko”. The malware downloads in a loop, 0x10000 bytes each time using InternetReadFile until the complete payload data is downloaded:

Downloaded data contains 0x40 garbage bytes in the beginning. Instead of keeping hardcoded decryption key, malware computes the key after downloading the encrypted data. The malware contains a constant byte array of 0x30b size. The malware executes in a loop, picks the first word from the constant byte array XOR it with loop index and again XOR it with the word after 0x40 garbage bytes in the downloaded data and if the value comes to “4D5A”, the malware breaks the loop. Now the loop index is XOR with the constant byte array to get 0x30B bytes decryption key:

 

The malware decrypts the payload data using the decryption key, which is the NanoCore RAT for this variant. However the other variants also downloads AgentTesla, NetWire RAT and Ramcos RAT etc.:

 

The file is detected by only a few security vendors on popular threat intelligence sharing portal VirusTotal at the time of writing this blog, this indicates its spreading potential:

 

Evidence of the detection by RTDMI(tm) engine can be seen below in the Capture ATP report for this file:

SonicWall Capture Labs Threats Research team has been regularly sharing information about malwares including spyware targeting Android devices. SonicWall has tracked down a huge number of fake applications disguised as legitimate Google update applications.

Fig 1. Fake Google Update applications

 

The new version of the spyware is recently available on malware-sharing platforms like VirusTotal.

Fig 2. VirusTotal submission history

 

Infection Cycle:

Most of the fake malicious google updater apps have some common activities of spyware and a few of them work as banking trojan as well.

After installation, the apps ask for Accessibility permission and then hide from the app drawer.

 

Fig 3: App Installation & Accessibility permission

 

It accesses the following activities on the device and tracked information is saved in the corresponding .json file and establishes a socket connection with C&C server “help.domainoutlet.site” and shares the device information in JSON file.

• SMS
• Call logs
• Call Recording
• Device Info
• Location
• Keyloggers
• Device Contact
• Notification

Fig 4: Storing contact details in JSON file

 

In some cases, along with spyware activities it also acts as a Banking Trojan, like SHA-256 fb3837dc602c3f51939891b75a34d706bbefa73f822cffffeb1b863a6526bf95 .

Dex file is dynamically loaded which contains the malicious banking trojan code.

Fig 5: Load Dex file

 

It checks for installed applications and compares them against specific package names preferably banking and Cryptocurrency apps (350+ apps). Once it determines that one of these apps is being used, it can carry out an overlay attack. In order to carry out an overlay attack, it places fake page over legitimate apps which looks similar to steal credentials.

Fig 6: Checking installed apps

 

Fig 7 : Load WebView for overlay attack

 

Fig 8: List of targeted apps

 

SonicWall Capture Labs provides protection against this threat via the SonicWall Capture ATP w/RTDMI.

 

Indicators of Compromise (IOC):

01d0e1996d0ba3ff4e0bac4747b0e0d955fe93ac3cca62caebc46dfd4f4b811f

1ac57a4bc06ebdd42ffed1d63e7731eade4a58c302641f3373f2a42298e461e2

299c10f9f438b8176b8f49654952d9189ddcf3b9e44e834c54db7410ac2af9f1

417ebc3a1dcc71f76d67b97adffd239399110b18eb644ef0da74061c7d569ef7

421f4aeedfec86eb756ac9acbb55014d973f2aa7136718cfd93829944998878a

65c9fd0fb77c08319ff8047f7c9302da843f8dcea9a8bad482850c9e3bd545cf

6a31addaad870460f0713fe057cb7a47fffe426f2217dcb2e0167b4257f356c0

763dc2a295d95ed24e2f9081ff192d079f9d6837f8e6ad15f6453542dd0c2ab9

85a710df11765d424f367abcbb61b70bbc42ef1969e7fd59968c784a8b5937da

8a15e9deb145e90cff2bf414842221afc04494c90d0a8af7e059e2273f661934

9d6ee58c17c62ef5ff8d586a6bea437dbaa856a0ac96c8e425063a55e23d6b11

c56862b2de6d04d15bc11f1dffed108099a3f0c92098383774580eadd551fc82

c745c5c4032e6b6036e25d1efad8f30470aee99f368a923509f570310e5d2644

cc8db772726e5d3d4ec680cd53587d79592c7a5a83148ff5b5ec0b7b7ce1781c

fb3837dc602c3f51939891b75a34d706bbefa73f822cffffeb1b863a6526bf95

 

Threat actor always targets under the radar file types to deliver malware to the victim’s machine. HTML Applications (HTA) files are known as less suspicious file types by various security providers. SonicWall Capture Labs Threat Research team has observed an HTA file inside an archive is being delivered to the victim’s machine, which further downloads and executes Smoke Loader malware.

 

Infection Cycle:

The archive file name is in German “Zahlungserinnerung-BV-Green-Golfm.zip” acted as a payment reminder for the victim. The HTA file has HTML code to display service estimation by “LM Classic Cars” for Ferrari 348 TB for an Autria customer, additionally it includes JavaScript code to download malware using PowerShell script:

 

The JavaScript code executes the PowerShell executable which further executes another instance of the PowerShell executable using Command Prompt:

 

The PowerShell script contains code to perform below actions on MS Office files:

• Enables all macros
• Disable protected view for files belongs to internet zone
• Disable protected view for attachments opened in Outlook
• Disable protected view for files in unsafe locations

The PowerShell downloads malware from URL h[t][t]p://www.trimm.at/error/upx.exe

 

The Smoke Loader malware works in multi stages and layers. It uses code obfuscation, anti debugging, anti VM and Living of The Land techniques. The malware makes sure that a memory dump should not expose its intention at any point of time.

 

First Stage Executable

The first stage executable is highly obfuscated, it contains large loops with garbage API calls followed by a conditional jump. The malware uses opaque predicate technique as control never goes to garbage API calls, they are just kept to make analysis difficult. In a long iterations loop, only few operations are actually required by the malware which are executed on a particular iteration. The below iteration loop is intended to calculate the encrypted bytes size at 0x40Ath iteration:

 

The malware decrypts the shellcode into memory which further brings second stage executable:

 

The shellcode uses PEB_LDR_DATA from Process Environment Block, iterates through InLoadOrderModuleList to get the API addresses. The shellcode decrypts next stage executable in memory and does process hollowing to replace current process from the address space and starts execution of new process from entry point:

 

Second Stage Executable:

Second stage executable code is full of techniques used to investigate the controlled environment execution.

Anti-Debug

Checking the BeingDebugged and NtGlobalFlag in Process Environment Block is common across the malware. Here the tricky part is, instead of branching the code based on the flag values, the malware uses the flag values to compute a jump offset. If the malware is running inside a debugger then it will compute a invalid address which makes an impression of corrupted file to the researcher:

 

 

On-Demand Decryption

The malware decrypts the code on demand just before executing it and once the code is executed, the malware encrypts it back. The malware does this, to prevent its complete code exposure in one shot:

Loaded module

The malware checks for below modules in the current process, if any of them is loaded malware terminates the execution.

• sbiedll (Sandboxie module)
• aswhook (Avast module)
• snxhk (Avast module)

 

Virtual Environment

The malware examines registry values “\REGISTRY\MACHINE\System\CurrentControlSet\Enum\IDE” and “\REGISTRY\MACHINE\System\CurrentControlSet\Enum\SCSI” for below substrings to check for virtual environment.

• qemu
• virtio
• vmware
• vbox
• xen

 

The malware enumerates through all the running processes and looks for below processes. If any of the process is found the malware terminates the execution. The malware shows laziness in the code here, instead of dynamic size for individual process name, the malware keeps the size to 0x20 bytes for all the process names:

• qemu-ga.exe
• qga.exe
• windanr.exe
• vboxservice.exe
• vboxtray.exe
• vmtoolsd.exe
• prl_tools.exe

The malware looks for below 7 bytes substrings of filenames into victim’s machine. If any of them is found the malware terminates the execution:

• vmci.s
• vmusbm
• vmmous
• vm3dmp
• vmrawd
• vmmemc
• vboxgu
• vboxsf
• vboxmo
• vboxvi
• vboxdi
• vioser

Code Injection

The malware gets the explorer.exe process id using APIs GetShellWindow and GetWindowThreadProcessId:

The malware creates and maps two sections in explorer.exe, one section has PAGE_READWRITE access attributes to store data and second section has PAGE_EXECUTE_READ access attributes to inject shellcode. Not enabling WRITE access to the shellcode memory makes the debugging little more difficult as this will prevent from putting software breakpoints and modifying code as per researcher’s need:

 

The malware injects shellcode into the mapped section and does NtCreateThreadEx passing data section address as parameter:

 

ShellCode Execution:

The Injected shellcode into explorer.exe spawns two sub-threads which keep an eye on monitoring tools. If the researcher opens any of the monitoring tool or analysis tool that will be immediately terminated by the sub-threads while the main thread doing its job.

Thread 1

This thread enumerates through all running processes, computes hash of the running process name and compares it with its list of hashes to terminate below processes:

• 56DAB1A9 → Autoruns.exe
• F3E35F5E → procexp.exe
• 2407724B → procexp64.exe
• FBC25850 → procmon.exe
• 27151A96 → procmon64.exe
• E6ED4551 → Tcpview.exe
• 27D7E006 → Wireshark.exe
• 2CEB6C62 → ProcessHacker.exe
• EDCD7F5E → ollydbg.exe
• 70A30042 → x32dbg.exe
• 4EA30D45 → x64dbg.exe
• 0CCD4A10 → idaq.exe
• 0CCD4C3A → idaw.exe
• 0956AD95 → idaq64.exe
• 337CAD95 → idaw64.exe

 

 

Thread 2

The malware enumerates through windows, computes hash value of windows name and compares it to terminate processes attached with below windows list:

• 61C75CDC → Autoruns
• 4DFA76EB → PROCEXPL
• 95E8B472 → PROCMON_WINDOW_CLASS
• 62DC4674 → TCPViewClass
• 6A0FAA84 → Wireshark
• 7FF991A1 → ProcessHacker
• BEDA6295 → OLLYDBG
• 62DD69FD → IDA

 

Main Thread

The main thread starts with Process Environment Block (PEB) traversal, to get ImageBase of ntdll.dll and kernel32.dll. The malware then enumerates the export functions to get the the addresses of required APIs. Instead of direct API names the malware keeps the hash values list, which is being compared to the hash value of the exported function name:

 

The malware keeps list of RC4 encrypted strings in a structure, in which first bytes tells the string size followed by encrypted string. The malware perform RC4 decryptions just before using them:

 

The malware computes a unique identifier for the victim’s machine using below formula:

MD5(computer name + hardcoded DWORD value + system drive serial number) +  system drive serial number

The malware creates mutex with the unique identifier to restrict execution of another instance of the shellcode and if another instance is already running malware terminates its execution:

 

The malware reads Internet Explorer version information from registry and gets user agent string for it:

 

The malware drops self copy into %APPDATA% directory and the file name is computed by encoding initial 7 bytes from the unique identifier:

 

The malware deletes the current instance of the malware and it deletes zone identifier from the self copy dropped in %APPDATA%:

 

The malware sets dropped file property as FILE_ATTRIBUTE_HIDDEN and FILE_ATTRIBUTE_SYSTEM. The malware steals creation time from advapi32.dll and mark the same creation time for the dropped file to avoid being red flagged from any of the security providers.

 

C&C Communication

The malware contains 4 C&C servers:

• ostgotahusbilsuthynring.de
• autoland-ls.de
• autogalerieseud.de
• autohuas-e-c.de

The malware calculate CRC32 checksum for one of the C&C server before communicating, to make sure that the C&C has not been modified by the researcher and if the C&C is modified malware terminates the execution. The malware prepares post data which includes the variant id, unique identifier for the victim’s machine, computer name and random 0xA1 bytes. The data is then encrypted by RC4 algorithm and sent to its C&C server:

 

At the time of analysis all 4 C&C server were not responding but digging deep into the malware code reveals that malware is expecting response from C&C server which should contain Variant ID (0x7E6), Plugin size and plugin modules.

 

Unavailability of the archive file in any of the popular threat intelligence sharing portals like the VirusTotal and the ReversingLabs indicates its uniqueness and limited distribution:

 

Evidence of detection by RTDMI ™ engine can be seen below in the Capture ATP report for this file: