During the recent BSIDES conference (2014), which was hosted in Las Vegas, Kyle Adams presented on "Evading code emulation: Writing ridiculously obvious malware that bypasses AV":

http://bsideslv2014.sched.org/event/7b5cb0af67cb7357cea44958a7cc29d1#.VITWpjGsWz4

During his presentation (video now available on YouTube) he discussed how 'clean looking code' can be used to bypass anti-virus (AV): https://www.youtube.com/watch?v=tkOtBkvS9xY

We recently identified some malware that uses some of the techniques detailed by Kyle, in order to bypass our AV scanner. What follows is a short analysis of the techniques used.

Merry Christmas, Santa Left You A Parcel…

It all started on the morning of December 4th when we received an e-mail purporting to be from FedEx. Figure 1 shows the e-mail. To our trained eyes this clearly appeared to be a Trojan or some sort of malicious phishing scam. Attached to the e-mail was a zip file Label_00000358165.zip.

Figure 1: FedEx email

We downloaded the attached zip file and calculated the MD5 sum; a Google search didn't find anything and further checks on Virus Total showed that the file had not yet been analysed.

The malicious zip file contained a file with a .doc extension for the weak souls to think it was a MS Word document.

Figure 2: unzipped malicious file showing a JavaScript with a .doc extension

This is where the fun started. The document actually contained some heavily obfuscated JavaScript, shown in Figure 3.

Figure 3: Obfuscated JavaScript

The JavaScript appears to consist of two large strings of random text delimited by spaces. When the script is run, these strings are split into arrays of sub strings at each space character. A nested loop is used to match strings from one array with the other larger array.

Each time a string match is found, the current loop counter value is emitted as a character into another string, which eventually builds up the un-obfuscated JavaScript.  Finally, “eval” is called on the un-obfuscated script string that has been built. Figure 4 shows a cleaned up version of the malware.

There is a high suspicion that this JavaScript was obfuscated with “MyObfuscatorPro”.

Figure 4: The decoder of the obfuscated script

After removing the “eval” call from the script, we were able to run it without risking infecting the network and obtain the plaintext.  This was achieved by placing the script into a custom HTML page as shown in Figure 5 and Figure 6.

Figure 5: Our “quick and dirty” HTML script evaluator

It can be seen that the obfuscation technique used in the script uses techniques investigated by Kyle Adams in his BSIDES talk.  Specifically, non-deterministic loops are used to encourage a virus checker JavaScript sandbox to “bail out” of analysis early.

Figure 6: HTML page used to decipher the JavaScript

After hitting the decode button (“Hit me to display the content of “c”), shown in Figure 6 we obtained the plaintext JavaScript.

Figure 7: The malicious script.

Figure 8: Cleaned up version of the Obfuscated JavaScript

JavaScript Analysis

Let's analyse the major function calls of this JavaScript.

The first line of the script creates a WshShell object. WshShell objects are used to run commands as if the command was typed in the command prompt.  This script builds its variables to create a command to execute as if it was typed on the command prompt. More details on WshShell can be obtained from http://msdn.microsoft.com/en-us/library/ateytk4a(v=vs.84).aspx.

The second instruction uses ws.ExpandEnvironmentStrings to retrieve the temporary directory of the infected system. The temp directory is then extended by a variable fn which will later hold the file name of the executable file (the malware).

On Windows 7 the string that will be passed to the command line will be similar to:

C:Users<current_username>AppDataLocalTemp<filename.exe>

According to the W3C working draft of 30th of January 2014, the XMLHttpRequest specification defines an API that provides scripted client functionality for transferring data between a client and a server. In this case, this malicious JavaScript will download data from a distribution server, capture the data and pass it back to the script to be saved with customised names (68957529.exe ; 19556738.exe ; 80058514.exe)

XMLHTTP is generally activated by default as seen in Figure 9.

Figure 9: XMLHTTP active by default

Once the data is passed back to the script, the script will check if the received data is of type binary [type =1]. The binary data is then saved into file [ xa.SaveToFile (fn,2)] starting from the first position of the binary file [xa.position =0];

"fn" is the parameter that holds the file name that will be used to save the binary data. More information about the ADODB.Stream can be found at http://www.w3schools.com/asp/ado_ref_stream.asp

We confirmed that this JavaScript attempted to download 3 pieces of malware in the temp directory as shown in a report of Microsoft Windows State Analyzer (Figure 10).

Figure 10: Windows State Analyzer capture

The file name was created but the content of the file was not downloaded. The network trace file shows HTTP response 404 indicating that the page was not found (Figure 10)

Figure 11: Network trace malware download

Since the file content was not downloaded, the operating system generated an error both on 32 bits and 64 bits Microsoft Windows OS when the JavaScript tried to automatically run the files (Figure 11 and Figure 12). Such alerts should have been managed by the malware writer to avoid alerting the user, asmost computer users will be suspicious after receiving such alerts.

Figure 12: execution error win 32bits

Figure 13: execution error on 64bits Windows 7

They are many reasons why the malware was not available for download:

• It is common practice that malware links get deleted or disabled once they have been found to distribute malware. It could have been the case that by the time we tried to download the malware, the files would have already been removed.
• It could have been the case that the malware files were hosted on a compromised server. Once the breach has been identified, the server will be patched and malware files will be deleted.
• Malware authors generally target a specific audience. It could have been the case that our IP address was out of the scope of intended infection.
• Simply, it could have been a mistake from the malware author i.e. they may have targeted the wrong URL.
  Writing malicious script using advertised clean functions from Microsoft will continue to be a problem for security. Even though some user elevation still requires the user interaction, it is very common that people accept messages without actually reading what action is to be performed.

It is anticipated that many new viruses will be delivered using JavaScript, as they can easily bypass AV. Hopefully, the payload of malware itself will be detectable by the AV. The JavaScript analysed on this article was received on the 4th December. Three days later, virus total has not yet flag that JavaScript as malicious.

As it was the case for Regin malware, the first stage of most malware infection is the downloader. AV has been traditionally good at detecting malware downloaders which are binary files. In this case, the malware author used JavaScript with functions that are used for legitimate purposes. In fact, most of the code from this malware can be found on the Microsoft website.

Our analysis did  find any record of the zip file flagged as malicious up to three days after we received the file. The first stage of this malware would certainly go undetected. To be successful in the second stage, the malware author would have use a recently packed or encoded payload to defeat AV detection. Also, the malware author could use a zero day which would definitely go undetected in this case. Every effort need to be made to stop malware in its tracks at each point.

So, how do you protect yourself against malware infection in this case?

Protecting against malware which is constantly changing can be very challenging. However, there are a number of factors that should be considered.

Security Awareness Training - User education is key, however, advanced attacks are specifically designed to get past unwitting or unaware users. Spreading malware through email is not a new technique but it still works. Users are generally tricked into clicking on files or links that are malicious. In this case, the end user had to open the zip file and double-click on the JavaScript file to be infected. User awareness is paramount for protecting against malware infection and we should still make sure our users are on their guard against these more hidden attempts

Anti-Virus - We can’t abandon AV either, even though it didn’t detect this instance of JavaScript as malicious. Using it as a second line of defence for known malware detection has its place, though it must be installed and frequently updated

Updates and patching - Perform regular updates as frequently as necessary to make sure that any malicious code does not take advantage of a known vulnerability

Monitoring and logging – Ensuring that you have the capability to detect changes and breaches is essential is responding to an attack. We can’t stop them all, so knowing when it happens to ensure action can be taken is a vital.

Find out more about security breaches and Nettitude’s approach here: https://www.nettitude.co.uk/cyber-breaches-response-in-depth/

To contact Nettitude's editor, please email media@nettitude.com.