Thursday, 7 February 2019

Multisandbox project welcomes SecondWrite

We are excited to announce the integration of  SecondWrite into the multi-sandbox project. The multi-sandbox project's goal is to aggregate many sandboxes in a similar fashion as the way we integrate Anti-Virus products. With this integration we are now up to 6 sandboxes including  ReaQta-Hive, Tencent HaboVirusTotal DroidyCyber adAPT ApkRecon and Dr. Web vxCube.  SecondWrite offers some cool features which we will detail below. 


In their own words:

SecondWrite’s next-generation malware detection engine delivers a combination of automatic deep code inspection and accurate scoring of zero-day malware. Its platform combines dynamic sandbox analysis with static analysis to leverage the best features of both. Its patented technology on forced code execution finds and executes hidden code paths that other sandboxes miss. It uses advanced neural networks that can auto-learn what suspicious code patterns to look for, without human-specified signatures. The neural networks are further enriched by its technology to detect evasive and anti-analysis features in malware.

To view the SecondWrite report make sure to check out the detailed report.


Within the detailed reports, for a quick summary, take a look at the detection scores and classifications.

Malware Score


Classification of different categories

Let's dig a little deeper and see some more features:

Forced Code Execution (FCE)

See for example the file  fcd6c16a61b286bb6951e49869fcadbc9bf83bccf31dc2e3b3c8f7ad23d6054f.

Within the detailed report you can see the IOCs generated by the FCE feature, extracted by SecondWrite's driver. In this example we see that the sample attempts to repeatedly call a a single API to avoid analysis. The FCE feature can rewrite one or more conditional statements to get the code sample to execute. Furthermore, some of the discovered events were characterized as Ransomware IOCs, Stealth IOCs, and Anti-Analysis IOCs.

 

Program-Level Indicators (PLI)

 


Typical hook-based approaches gather information about program behavior by capturing application to library function calls and application to kernel system calls. This approach is very effective at capturing how an application interacts with the underlying system through supported Application Program Interfaces (APIs), but it completely misses classes of evasion techniques intended to modify a program running in memory. SecondWrite's Program-Level Indicators are patterns that can only be discovered by looking at the assembly instructions themselves. Frequently the instruction sequences chosen by malware have second-order effects that are beneficial only to malicious programs attempting to hide something. The following report contains two such examples: anti-binary translator code to defeat static analysis and an Import Address Table (IAT) bypass.



Machine learning can be very effective at finding subtle, multivariable associations that are impossible for a human to find. The most granular dataset to feed to a machine learner is sequences of assembly instructions. SecondWrite's Automatic Sequence Detection technology is able to discern instruction sequences that are only found in malicious applications and give a confidence level. It is precise enough to limit false positives, but also broad enough to not be susceptible to artificial changes injected to malware strains such as is the case with polymorphic malware. The following report shows a sample that was determined to be malicious by Automatic Sequence Detection with a 93% confidence:
https://www.virustotal.com/gui/file/520c376e726ca11d47566cbbd03f764646c4e498d76b8457e4cf28e940ca79f1/behavior/SecondWrite

Next we can click on the relations tab, we can see how it's related to other IP Addresses, Domains, and URLS.


In this graph we can see related files based on network communication, with common URLs, Domains and IP addresses:



Tuesday, 15 January 2019

Distribution of malicious JAR appended to MSI files signed by third parties

Microsoft Windows keeps the Authenticode signature valid after appending any content to the end of Windows Installer (.MSI) files signed by any software developer. This behaviour can be exploited by attackers to bypass some security solutions that rely on Microsoft Windows code signing to decide if files are trusted. The scenario is especially dangerous when the appended code is a malicious JAR because the resulting file has a valid signature according to Microsoft Windows and the malware can be directly executed by Java.

Code signing is the method of using a certificate-based digital signature to sign executables and scripts in order to verify the author's identity and ensure that the code has not been changed or corrupted since it was signed by the author.[1] This way, for example, if you modify the content or append any data to a signed Windows PE (.EXE) file the signature of the resulting file will not be valid for Microsoft Windows, as expected. This behaviour changes when you append any data to the end of a signed Windows Installer (.MSI), the resulting file will pass the verification process of Microsoft Windows and will show just the original signature as valid without any other warning.

This behaviour could be used to hide and distribute malicious code in MSI signed files, in fact several security solutions rely on the output of Microsoft Windows code signing validation to avoid an in-depth scan when the file has a valid signature by a well-known and trusted software developer. Such an attack vector is not very interesting if the resulting file is not designed to execute the attached payload, because the attacker would need an additional component already running in the target to extract and execute the appended malicious code. However, JAR files have a characteristic that allows them to run directly in this scenario, making them the perfect candidate to take advantage of this situation.

A JAR file allows Java runtimes to efficiently deploy an entire application, including its classes and their associated resources, in a single request.[2] The interesting part for exploiting the commented scenario is the JAR file format is based on ZIP to store the different components and resources, and this kind of ZIP is correctly identified by the presence of an end of central directory record which is located at the end of the archive to allow the easy appending of new files.[3] When Java opens a JAR file it looks at the end instead of the beginning of the file, so a JAR file is executed independently of the data at the beginning of the file. In addition, on Microsoft Windows systems, the Java Runtime Environment's installation program will register a default association for JAR files so that double-clicking a JAR file on the desktop will automatically run it with "javaw -jar". Dependent extensions bundled with the application will also be loaded automatically. This feature makes the end-user runtime environment easier to use on Microsoft Windows systems.[4]

In short, an attacker can append a malicious JAR to a MSI file signed by a trusted software developer (like Microsoft Corporation, Google Inc. or any other well-known developer), and the resulting file can be renamed with the .jar extension and will have a valid signature according Microsoft Windows. For example, via the command "copy /b signed.msi + malicious.jar signed_malicious.jar". The victim can be infected with just a double-click in such a file.

This attack vector was detected in a sample sent to VirusTotal and flagged by VirusTotal Monitor (a service to detect and avoid false positives).[5] We have not found evidence of this technique being used massively to distribute malware.

We would like to thank Mark Russinovich and Mark Cook from Microsoft for working with us in the study of the issue and their quick response with a Sysinternal's Sigcheck update to detect this kind of malformed files.[6] VirusTotal also detects this attack vector via the updated version of Sigcheck with the warning "Signed but the filesize is invalid (the file is too large)" in the Signature info section.[7]

Thanks also to Microsoft Security Response Center for the study of the issue. This attack vector has been verified in the latest and updated versions of Windows 10 and Java available at the timing of writing (Windows 10 Version 1809 and Java SE Runtime Environment 8 Update 191). Microsoft has decided that it will not be fixing this issue in the current versions of Windows and agreed we are able to blog about this case and our findings publicly.

Last but not least, thanks to all our security partners at VirusTotal for making Internet safer. An early version of this blog post has been shared with all of them in order to provide an adequate response to detect and stop these types of attacks with their antivirus, antimalware and next-gen solutions.


[1] Code signing [Wikipedia] https://en.wikipedia.org/wiki/Code_signing

[2] JAR (file format) [Wikipedia] https://en.wikipedia.org/wiki/JAR_(file_format)

[3] Zip (file format) [Wikipedia] https://en.wikipedia.org/wiki/Zip_(file_format)#Structure

[4] JAR File Overview [Oracle] https://docs.oracle.com/javase/6/docs/technotes/guides/jar/jarGuide.html

[5] VirusTotal Monitor [VirusTotal] https://www.virustotal.com/#/monitor-overview

[6] Sigcheck 2.70 [Microsoft Sysinternals] https://blogs.technet.microsoft.com/sysinternals/2018/10/21/sigcheck-2-70-bginfo-v4-26-and-vmmap-v3-22/

[7] Signed .MSI with malicious JAR appended [VirusTotal] https://www.virustotal.com/gui/file/dd71284ac6be9758a5046740168164ae76f743579e24929e0a840afd6f2d0d8e/details


Francisco Santos & Bernardo Quintero

Tuesday, 8 January 2019

Multisandbox project welcomes ReaQta-Hive

We are pleased to announce the addition of ReaQta-Hive to the multisandbox project, after the integrations of Tencent Habo, VirusTotal Droidy, Cyber adAPT ApkRecon, and Dr. Web vxCube. The unique new feature that this integration brings is XSL documents in addition to  PE files, PDF, MS Office documents and scriptlets.

In their own words:

ReaQta-Hive is an Endpoint Threat Response and Hunting platform that uses A.I. to detect new types of attacks. A live hypervisor, called the NanoOS, collects detailed security information at the lowest possible level of an endpoint, which Hive uses to perform dynamic behavioral analysis. This analysis is automatic and constructs a comprehensive storyline of an attack. The end result is an intuitive report of all the actions carried out by an attacker, including a summary of the meta-behaviors that highlight key components of the attack. ReaQta-Hive is a vector-agnostic platform, so it can analyze the behavior of any type of attack, whether it is file-less, script-based, exploit driven, or a plain executable file. We are happy to use our software and expertise to contribute actively to the VirusTotal community, and to help analysts worldwide be more effective and efficient.


To view the ReaQta report when viewing a file analysis, click on the Behaviour tab, select  ReaQta-Hivethen the detailed report.



In the detailed report, you can view copious amounts of information obtained by ReaQta-Hive:


Lets take a look at some example use cases where this data is interesting. 

XSL document  / #squiblytwo

This example is an interesting malicious XSL document which only ReaQta processes:
https://www.virustotal.com/#/file/9d3746779bc2b2d1ecbd90da8626f81978db4be1eb346106a6334295fce568cd/behavior 
In the relationships tab you can see a  link to VT Graph where you we can see some relationships to other domains and URLs VirusTotal has seen before.


 

Malicious document using LOLBins

Malicious code using Living off the land binaries and scripts (LOLBins) have become popular since they are binaries/scripts that are included with the operating systems, hence trusted. Here is a MS Office trojan that does so: 
https://www.virustotal.com/#/file/1f4f22f1814712880b2bbdc5c6418aeaf08c598be0990c5fad55136c9e769951/behavior 

 

Windows PE file, detecting behaviors like  key-logging/screenshots

https://www.virustotal.com/#/file/d72f74208c8960ae70469af3968324c6d5f90a305931763c0f5e23cd7922bcea/behavior
In the report we can see the detection and severity:


Tuesday, 18 December 2018

VirusTotal += Acronis

We welcome Acronis scanner to VirusTotal. In the words of the company:

“Acronis PE analyzer is Machine Learning based engine to be a part of upcoming cyber protection suite that company will release in 2019. It is a further evolution of Acronis AI capabilities that were introduced in 2018 to combat ransomware. PE analyzer is able to detect any kind of windows PE malware due to optimized innovative machine learning models. Acronis has plans to continuously improve the engine before and after the release of above mentioned cyber protection suite to bring value to all VirusTotal users.”

Acronis has expressed its commitment to follow the recommendations of AMTSO and, in compliance with our policy, facilitates this review by AV-TEST, an AMTSO-member tester.

Thursday, 22 November 2018

VirusTotal += Trapmine

We welcome Trapmine scanner to VirusTotal. In the words of the company:

“Trapmine ThreatScore is a machine learning-powered malware detection engine developed to identify known and never-before-seen malware. This engine is a part of TRAPMINE Endpoint Detection & Protection Platform. Trapmine combines machine learning, behavior monitoring and endpoint deception techniques to provide fool-proof defense against malware, exploit attempts, file-less malware, ransomware and other forms of targeted attacks. Windows PE files submitted to VirusTotal will be analyzed by Trapmine ML engine and the verdicts will be displayed to VirusTotal users.”

Trapmine has expressed its commitment to follow the recommendations of AMTSO and, in compliance with our policy, facilitates this review by MRG Effitas, an AMTSO-member tester.

Tuesday, 19 June 2018

Launching VirusTotal Monitor, a service to mitigate false positives


One of VirusTotal’s core missions is to empower our antivirus partners. By building better tools to detect and study malware, VirusTotal gets to make a dent in the security of billions of users (all those that use the products of our partners). Until now we have focused on helping the antivirus industry flag malicious files, and now we also want to help it fix mistaken detections of legit files, i.e. false positives. At the same time, we want to fix an endemic problem for software developers.

False positives impact antivirus vendors, software developers and end-users. For example, let us imagine a popular streaming service app that allows in-app digital content purchases. We will call it Filmorrific.

Filmorrific happens to be so popular that when an antivirus vendor mistakenly flags it as malware, the AV vendor gets terrible press as major online news sites, computer magazines and blogs report on the issue. This leads to big reputation damage for the AV vendor.

The detection of Filmorrific leads to the software being quarantined and blocked from running on end-user machines. End-users are now unable to access their favourite streaming service, and they are also confused, thinking that Filmorrific has trojanized their machines.

For Filmorrific, the software publisher, this immediately translates to blacking out in the entire user base of the detecting AV vendor. Suddenly, they not only lose revenue coming from the installed base, but also trust from less technical users that do not really understand what is going on, and they get overloaded with support tickets accusing them of infecting user machines. Filmorrific in turn decides to sue the detecting antivirus company for the damage, and we have now come full circle.

Note that in this context, a software developer is not only a company creating an app or program distributed to thousands of machines and including some kind of monetisation strategy. Today, almost every organization builds internal tools that their finance, accounts payable, HR, etc. teams use. All of these tools are prone to false positives, and while this might not have a revenue impact, it certainly has a cost in terms of productivity hours lost because the workforce can’t access a given app.

What if we could kill these three birds with the same stone? Enter VirusTotal Monitor. VirusTotal already runs a multi-antivirus service that aggregates the verdicts of over 70 antivirus engines to give users a second opinion about the maliciousness of the files that they check. Why not take advantage of this setup not only to try to detect badness, but also to flag mistaken detections of legit software?

VirusTotal Monitor is a new service that allows software developers to upload their creations to a private cloud store in VirusTotal. Files in this private bucket are scanned with all 70+ antivirus vendors in VirusTotal on a daily basis, using the latest detection signature sets. Files also remain absolutely private, not shared with third-parties. It is only in the event of a detection that the file will be shared with the antivirus vendor producing the alert. As soon as the file is detected, both the software developer and the antivirus vendor are notified, the antivirus vendor then has access to the file and its metadata (company behind the file, software developer contact information, etc.) so that it can act on the detection and remediate it if it is indeed considered a false positive. The entire process is automatic.

For antivirus vendors this is a big win, as they can now have context about a file: who is the company behind it? when was it released? in which software suites is it found? What are the main file names with which it is distributed? For software developers it is an equally big win, as they can upload their creations to Monitor at pre-publish stage, to ensure a release without issues. They can also keep their files in the system, to automate notification of false positives to antivirus vendors in the future. Software developers no longer have to interact with 70 different vendors, each having its own interface and strenuous process to communicate issues.

In particular, software vendors use a Google-drive like interface where they can upload their software collections and provide details about the files:


Upon upload, the files are immediately scanned with the 70+ antivirus engines in VirusTotal, and then once a day thereafter. At any point in time you can refer to the Analyses view in order to see the health of your collection with respect to false positives:


All of this scanning activity is summarized in the dashboard where users land on subsequent accesses to the platform:


Developers are not forced to use this web interface, as the platform allows email notifications and offers a full REST API that is very useful when automating software release pipelines:

On their end, antivirus vendors also see something similar. They get access to a platform with all items that the particular engine detects and they can integrate with it programmatically via a different API endpoint. This is how certain vendors are able to quickly react and get over 200 false positives from our test bed fixed within minutes:


As previously stated, all files in this flow are private; they are not distributed to third-parties, only to antivirus vendors producing detections. This said, if one of the files in a Monitor collection happens to be uploaded to the standard public VirusTotal service, we will highlight that the file belongs to an organization in Monitor and will display the pertinent detections in orange rather than red:


VirusTotal Monitor is not a free pass to get any file whitelisted, sometimes vendors will indeed decide to keep detections for certain software, however, by having contextual information about the author behind a given file, they can prioritize work and take better decisions, hopefully leading to a world with less false positives.  The idea is to have a collection of known source software, then each antivirus can decide what kind of trust-based relationship they have with each software publisher.

As Marc Andreessen once said, “software is eating the world”, however, there is not much it can eat unless it can actually execute -- let’s make sure that legit software can run.

Tuesday, 5 June 2018

Multisandbox project welcomes Dr.Web vxCube


The multisandbox project keeps growing, short after the integration of Tencent Habo, VirusTotal Droidy and Cyber adAPT ApkRecon we are now welcoming Dr.Web vxCube. What is most exciting about this integration is that not only does it run executables, but also opens documents with potentially vulnerable software in order to spot exploits and characterize dropped malicious payloads.


In their own words:
Dr.Web vxCube was born inside Doctor Web Anti-Virus Laboratory. It is a hypervisor-based sandbox that uses agentless technology to analyze malware inside the operating system. It works incredibly fast and invisibly to the analyzed sample. Dr.Web vxCube offers comprehensive but intuitive reports containing information about sample's behavior, created files and dumps, process graph, API log and network activity map. We are happy to bring our expertise to the VirusTotal community.


The following report examples highlight how useful this new integration is:


The following ones are particularly interesting as they exemplify how Dr.Web vxCube is able to spot exploitations triggered when opening a document, most specifically exploitation of CVE-2017-11882:


Make sure you also open the detailed report:

This will open up a far more insightful HTML capturing fine grained execution details that are presented in an aggregate fashion in the summarized behavior tab or perhaps not even included at all:


Behavior information is essential when diving into investigations because it allows analysts to pivot over certain indicators of compromise and discover other malicious files and network infrastructure that is related to the same campaign or attacker group. For instance, if we focus on the first CVE-2017-11882 file and open it up in VirusTotal Graph:



We can immediately get a sense of the file indeed being malicious (due to its connection to malicious items) but we may also easily discover the network infrastructure used by it, and most importantly, we get to see other malware served by that very same network infrastructure, without having to follow a huge amount of report links:



And this is precisely how we discover some of the deception techniques being used by the attackers behind this particular threat. The exploiting document communicates with a-dce.com, so do 3 other samples. By investigating these in VirusTotal Intelligence we get to see that some of those files were spotted as attachments in spam email files uploaded to VirusTotal, we can see the body of these messages and discover how they trick users into downloading and opening the exploiting document:





Fake purchase orders and invoices remain a common simple bait inducing users to execute malware. Having reached this point it would be a good moment to build a Yara rule to detect variants of this malware family and set them up in Malware Hunting in order to discover new threats created by the very same group and keep expanding the investigation graph.

We hope you find this new sandbox as exciting as we do. We already have more integrations in the pipeline and we are certain this will heavily contribute to identifying new threats and strengthening anti-malware defenses worldwide.


If you have a sandbox setup or develop dynamic malware analysis systems please contact us to join this effort.