Introducing A Unique Script Logging Engine

One advantage of being an exposed software vendor (we operate a popular free public malware analysis service) is that we constantly get challenged with latest malware samples and have a vivid feedback loop. IT-Security professionals and researchers from all around the world upload what they get in touch with at a daily basis. As we are quite dedicated about what we do here at Payload Security, we monitor the webservice closely and enjoy in doing so.

We have been observing that during the past months usage script languages as an entrypoint stage has been growing quite popular among cybercriminals. Often, it is not a single-layer approach, but the actual malicious script is downloaded by a "pre-stage" VBA script or other intermediate stages. That is, we have been seeing multi-layered dropper scripts. In general, one could say that mixing all kind of script formats, including javascript, powershell, vbs, wrappers (wsf/hta), encoded formats (jse, vbe) and other variants has become a standard toolset of the delivery process. Taking a look at the statistics page of the webservice underlines the growing popularity of using scripts (and not even counting AutoIT compiled to PEs, etc.):

A brief look around quickly revealed that other AV vendors have noticed scripts being a popular vehical to deliver trojans, ransomware, RATs, etc. As most of these scripts are not sandbox environment aware, it is our personal speculation that the current increase in complexity of malware delivery has mostly been implemented to bypass endpoint protection solutions, which often also rely on parsing the input file and the commandline pre-execution. Nevertheless, there is sandbox evasive mechanisms built into scripts that are interesting to investigate, as well.

In order to better understand malicious script activity, we have implemented a generic script logging engine (hint: we are still thinking of a fancy/fluffy marketing name) that is quite powerful and intercepts various external script calls (JS/VBS/VBA). It is a technology that we are still building upon, which has been turned on at the public webservice for a few weeks now. As we are quite excited about it already, we decided to push forward the news with this blogpost.

Multi-Layered Cerber Delivery

The new Cerber variant we will be looking at right now uses a typical social engineering technique to try to lure receivers into enabling macros and execute the payload:

In general, reports of VxStream Sandbox always contain a variety of indicators that allow quick assessment of macro codes and whether or not they are most likely malicious (e.g. detecting obfuscation, suspicious keywords, auto-execute functionality, etc.):

In general the macro indicators are not useful beyond determining general malicious intentions. This is where the new script logging engine comes into play, which adds some forensic flavor and allows extracting more artifacts. In order to access the script engine output, one must go to the 'Hybrid Analysis' process details section and click on a process that has the "Logged Script Calls" cog icon next to it:

In this specific case, clicking on the process will take you directly to the "Script calls" tab:

As we can see, the obfuscated VBA code is actually unwrapping a piece of javascript, which in turn is downloading (and verifying) the next stage, which ends up being a PE file encrypting the machine:

As this is happening within the VBA engine, neither classic API call monitoring nor instruction based tracing (as implemented by some "next generation" solutions) will easily yield this depth and clarity.

Link to the report: https://www.vxstream-sandbox.com/sample/3004c162dc360c97aefc7828ca175e65583b972c9a7444d4f0e05d7bc4dc71f9?environmentId=100

Another beautiful example of the new script engine is the following Nemucod trojan delivering a malicious javascript as a Windows Script File (WSF). It is deeply layered involving multiple stages, including WScript.Shell and PHP code, as can be seen quite nicely by the process tree and the "Script calls" tab:

Link to the report: https://www.vxstream-sandbox.com/sample/b9618fd0f7dcfc47ea725c817abee20fde0298ee64783565766b38b53d5a0869?environmentId=100

Conclusion

As discussed, we believe there is a trend towards mainstream malware using more complex delivery methods that involve multi-layered scripts. For us at Payload Security one answer to the ever-changing IT-security threat landscape is to try out novel ideas, not being "scared" of field tests with in-the-wild malware, being transparent about technology (we do not believe in security through obscurity) while keeping a focus on implementing solid solutions that bring business value to the end user.

Did we get your interest? Try out the new script logging engine at https://www.hybrid-analysis.com/ or follow us on Twitter at https://twitter.com/payloadsecurity

Financial malware delivered via embedded JSE

Just a few days ago our research lead came accross an interesting office file. Instead of the common macro malware everyone sees today (which is as old as the 90's, albeit still successful), the sample we were looking at was using an interesting way to bypass automated detection: the Office file contained an additional embedded file, which needs to be launched "manually" (double-click) and at first sight of the icon seemed to be an Excel sheet.

As the "follow the instructions" type of prompts are usually a dead give-away for malware (amazing that these things still work), we decided to take take a deeper look and see if we might possibly learn a lesson and improve our own automated malware analysis system. What made the file even more interesting is that it was bypassing all major sandbox vendors (including our own, to be fair) and had a very low AV detection rate. Nevertheless, it did have AV detection, which - by the way - is a strong statement in our opinion and underlines that leading AV technology is still very important, at the very minimum as an initial filtering mechanism.

... but enough of the ramblings, let's get down to the nitty-gritty. ;-)

 

Initial Assessment

 

As a first (manual) step, we took a brief look at the Word file structure.

The embedded 'oleObject1.bin' file is the 'Excel file' that one can observe when opening the Word file (see first screenshot of this blogpost). Let's take a brief look at it:

... aha! The file contains a Javascript Encoded (.jse) file reference. You can either drag & drop the embedded 'Excel sheet' from the Office file or take a closer look at the binary contents to find the encoded javascript.

Obviously, the embedded JSE is very difficult to parse statically and does a good job at hiding IOCs. The random dictionairy comment (see the "/* */" in the above image that encapsulate a large chunk of white noise, most likely to create an acceptable valid vs. junk character ratio to bypass heuristic AV thresholds).

 

Improved Sandbox Results

 

Let's skip forward two days and take a look at our optimized VxStream Sandbox report for the file. As of v4.4.0, we successfully extract embedded .jse/.vbe files from Office files and execute them on the target system as well as decode them automatically and try to extract IOCs from the decoded (and partially deobfuscated) version of the script(s). Here are the results:

Launching the embedded JSE on the Windows guest

Decoded JSE available for D/L

 Taking a peek into the decoded JSE

Extracting the IOC from the "IP address" Behavior Indicator

 

Conclusion 

 

The file we reviewed in this blogpost demonstrates that malware groups are very agile and remain 'creative' at bypassing security systems, especially automated sandbox systems. This underlines the importance of having an agile sandbox framework to quickly adapt to new techniques, but also shows that awareness of sandbox systems is growing. In this specific case, a clever mix of social engineering tricks (the fake 'Excel sheet' icon), added white noise (the legitimate string data) and an uncommon trigger (human interaction required to double-click the embedded file; no usage of macros) as well as the more hideous JSE was observed. It is a prime example to show that it is not enough to simply execute a file in a sandbox environment. Instead, at the very minimum, a carefully crafted mixture of static and dynamic analysis techniques is necessary to stay on par with latest malware evolution. A broad term we defined at Payload Security for the combination of static and dynamic analysis techniques is Hybrid Analysis.

(1) VxStream Sandbox Report: https://www.hybrid-analysis.com/sample/4fd53f748006c7f7729cd3360ec8a9a50740e253cb2583f5330fd5e35b64cb04?environmentId=100
(2) Dropped Gozi Report: https://www.hybrid-analysis.com/sample/d945dcd6e3c1e3bff7536d5cf099780d9fdc7ad9efa31752e7b287dce66b194b?environmentId=100

UPDATE

 

We were made aware of the following excellent blogpost  that outlines a quite similar attack, but instead of using an embedded JSE camouflaged as an Excel sheet, a batch file launching Powershell with a Base64 encoded "dropper commandline" was observed. We filled our coffee cups and made a small night session to accomodate for any kind of embedded file type. Here are some impressions:

 Targetted Powershell Attack

 Improved VxStream Sandbox Report

(3) VxStream Sandbox Report: https://www.hybrid-analysis.com/sample/831f8bb592de20929e171ad951f33ad697bcb79f122061f7a450106219733eb7?environmentId=100

Follow @PayloadSecurity