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

About Dridex, decoding and deobfuscating VBE files, behavior signature triplets and other features

Decoding and deobfuscating embedded VBE files

We will start out this blogpost outlining the technologically speaking probably most exciting feature that we added recently: VxStream Sandbox is now able to detect, extract, decode and deobfuscate VBE (encoded visual basic) macros from input samples. This is a feature we are quite proud of, because we are probably the first and only sandbox that is capable of doing so. We would like to demonstrate the feature on a sample that someone just recently made us aware of: it's a dridex variant (the hash / sample is available at the bottom) that appears in form of a Windows shortcut file and contains an embedded VBE macro as part of its overlay. The sample does not yield good results on some 'APT industry leader' solutions, as we have heard. Anyway, what our system will do is the following:

• Detect embedded VBE files
• Carve them out as an 'extra file' for analysis
• Decode the VBE file to a VBS file for later post-analysis-analysis
• Launch the carved VBE file additionally to the input sample (in case the input sample fails to launch its payload)
• Deobfuscate the decoded VBE file
• Put all that information into the report and have it reflected as part of the Threat Score

The steps an analyst would usually need to take to extract/decode and deobfuscate the macro (to obtain e.g. the malicious URL) would be quite time intensive, so seeing all that in an automated fashion happening within minutes makes us quite happy. The following screenshots will give you just a brief excerpt of the most stunning parts of the report:

As can be seen, it is possible to even download the decoded *.vbs file for further analysis. Also, an interesting conclusion of this sample, especially if the actual payload is not executed, is that pure static analysis can be a very powerful tool when analyzing macros. It might be generic to instrument VB execution and extract data, but that always depends on a successful execution (i.e. what if the file doesn't run as expected?). That's why we believe in the combination of both dynamic and static analysis techniques: something we try to describe as 'Hybrid Analysis'.

Report (including download of sample): Here

Other progress

It is difficult to stay up-to-date with all the feature we add to our webservice, because there is no published changelog. That's why every now and then we like to make a blogpost that gives some insights, but also to recap and archive the development progress we made for ourself. Looking at our public webservice as a visitor, there is two places you can use to indirectly see the development:

Version number on the front page

Total behavior signatures

The total number of behavior has been on a constant rise since we went online late 2014. Whenever we find a new interesting sample, we check if there is some malicious/suspicious behavior that can be turned into a generic and replicable signature. For example, we just recently added a 'Sample was identified as malicious by a large number of Antivirus engines' signature in addition to the previous 'Sample was identified by at least one Antivirus engine'. The new signature has a far higher relevance on our internal 'Threat Score' calculation, because if 25% of 50+ AVs agree that a file is malicious, the chances of a false positive is quite low. While this isn't an example for a generic signature, it is a good example of the gradual and constant improvements that happen to our system all the time.

Incident Response Section

After getting some feedback of incident responders we decided to add a new section called 'Incident Response' that contains a 'Risk Assessment' and a 'Network' area. The 'Risk Assessment' area basically displays some more broad categories (such as 'Spyware/Leak') depending on whether a signature or a combination of signatures matched (configured internally). The idea behind it is to answer the question 'How worried should I be?' (e.g. if the submitter knows an information leaking file was executed on a computer in the finance dept.). 

The 'Network' area is a summary of what you would find in the 'Network Traffic' section to allow quick response based on the IPs and domain names. Ovearll, it does not contain more information than you would be able to read by sifting through the report, but it can save some time on a first glance. This is still a work in progress.

Platform Intelligence Section

The 'Platform Intelligence' section is also new and may appear on malicious reports. It is the beginning of a broader development agenda that we want to learn about a file by comparing/associating its data with data from other reports on the platform. As the database is growing (we have about 30k reports online right now), there will be more and more useful applications.

The first feature implemented as part of the 'Platform Intelligence' section is the 'Report Behavior Comparison' section, which - under the hood - is quite effective in regard to determining if a file is malicious if the report database is large and diverse. What we noticed was the following: if one looks at a single behavior signature (e.g. 'Contains ability to retrieve keyboard strokes') it is often not a strong enough indicator to make a verdict about the file (think of an installer, which is often packed, drops files, shows network activity, sets an autostart registry key, etc.). When one looks at certain combinations of signatures though (e.g. 'Contains ability to retrieve keyboard strokes' AND 'Writes data to a remote process' AND ...) and you check each combination against every report (benign or malicious) in the entire database, it is possible to isolate signature combinations that are unique to malware. Using signature combinations, it is also possible to classify malware, but we have not gone that far yet. Anyway, what we can say is: the larger the number of signature tuples, the higher the confidence will be, but the more specific to certain malware families. Again, this is still a work in progress, but what is nice about the implementation is that we calculate all tuples on-the-fly based on a live snapshot of all triplets of all malicious reports in the database (i.e. if you refresh a report the next day, you might see different data). This feature has been a research topic of one of our main developers some years ago, and because it is still a work in progress and relatively experimental, the results of the section are not added to the 'Threat Score', but just displayed as an additive to the rest of the report.