Wednesday, February 24, 2016

Saved by an abundance of caution - Firefox w NoScript


My default browser is Firefox with NoScript. It is a pain, a lot of things do not work including slimy redirects with possibly malicious intent. Earlier today, I wrote the Advisory Board about using someone’s picture and story for the SANS Boston 2016 Brochure. I got a couple replies so when this came in I ASSUMED it was another reply and clicked on it; dumb. It is a redirect. But I was saved by my operating environment. Now, how to find out how to cause redirects to send me a popup asking for my permission.

= = = 
Email had no subject, (Link has been modified for safety):
   


Best regards,
Blake Andrews
= = =
Result, (thank you NoScript):


Monday, February 15, 2016

Javascript Ransomware Attack

Defending the Endpoint from Ransom32 and JavaScript Malware
ISE 6100 Security Project Practicum - Technical Paper
Authors: David Martin
Kevin Varpness
Advisor: Stephen Northcutt
Due: February 11, 2016



Abstract



While JavaScript has long been used to enable drive-by downloads and exploit browsers, it is now possible to write JavaScript ransomware, as demonstrated by the recently discovered Ransom32 malware. The newly demonstrated viability of JavaScript malware payloads in concert with its cross-platform nature increases the likelihood of attacks against Linux and Mac platforms. Because of this, GIAC Enterprises is reviewing its exposure to malware written in JavaScript (Ransom32 in particular) whether it is run in an executable file with its own interpreter, inside a browser, or inside any other mechanism on Windows and Macintosh OS X systems. The goal of this project is to provide research on the defensive options to counter the vulnerability to JavaScript malware and provide recommendations to improve the security posture of GIAC Enterprises.


1.            Introduction

On December 29, 2015, users of the computer support website BleepingComputer.com first reported infections from a new ransomware variant, known as Ransom32. While ransomware has become quite common in recent years, Ransom32 was unique, not only for its enormous 22 MB file size but for the fact that it was programmed in JavaScript and packaged with an NW.js interpreter (Abrams, 2016). Early analysis of Ransom32 indicated that it could easily be adapted to target Macintosh OS X or Linux systems, which had not previously been targeted by ransomware (Fabian, 2016). Because of this evolution and the potential damage ransomware could cause our business, GIAC wishes to evaluate defensive measures to protect against JavaScript malware, with a particular focus on Ransom32.  The goal of this project is to research the threat vectors by which JavaScript malware can impact GIAC Enterprises and defensive options to reduce our vulnerability to JavaScript malware in general and Ransom32 in particular. 
GIAC Enterprises is in a relatively unique position because its employees use MacBook’s as their endpoint workstations and much of its work is done by independent contractors who operate on their own personally owned computers outside of the direct control of GIAC. In order to manage the OS X endpoint systems, which lack the built-in enterprise management capabilities of Windows Active Directory, GIAC has deployed JAMF Software’s Casper Suite. This software provides the ability to deploy a standard operating system image and manage approved software, user accounts and settings after deployment without the need to physically access multiple endpoint systems.
With this goal in mind, we researched a variety of security solutions GIAC may implement to protect both Windows and Mac OS X endpoint systems. The research included conversations with vendors, online research, online demonstrations, and hands-on testing of possible implementations. Based on the outcome of this research we are able to offer a number of simple, low-cost measures that, if implemented, will immediately decrease the vulnerability of GIAC employees’ and contractors’ endpoint systems. We have also identified enterprise endpoint protection products that could be provided to employees and contractors to increase their security.

2.            Ransom32 Malware Threat

            The Ransom32 malware holds the ignominious distinction of being the first known ransomware written in JavaScript. Reports indicate that it is being sold on the “dark web” using a “ransomware-as-a-service” business model (Storm, 2016). Ransom32 leverages the Node-Webkit (NW.js) framework that allows JavaScript code to be executed on any operating system for which an NW.js interpreter exists (currently Windows, OS X and Linux). Another dangerous feature this framework provides is removing the barriers present in traditional browsers, and allowing JavaScript code to interact directly with the local file system. This allows the JavaScript to be used for functions previously only allowed by scripting languages like Python or Perl.  Currently, only Windows versions have been reported, but the NW.js framework allows for easy cross-platform development and it would likely be relatively trivial to port Ransom32 to OS X or Linux (Fabian, 2016).
            With just a Bitcoin address, cyber criminals can sign up for the ransomware-as-a-service through a hidden server on the Tor network.  This gives them access to an interface that generates the malware, after which delivery to its victims is the responsibility of the purchaser. The generator handles the ransom payment mechanics in exchange for a percentage of the ransom. Reports have surfaced of Ransom32 being delivered by phishing campaigns, through drive-by downloads, and possibly other delivery mechanisms (Storm, 2016).
            The Ransom32 malware consists of a self-extracting RAR archive, which uses the WinRAR scripting language to extract the malware to a temporary location and execute it.  The archive is an alarming 22 megabytes in size, which is significantly larger than traditional malware.  The archive holds a text file of a GPL license, the NW.js package containing the malware disguised as Google Chrome, a Tor client, an Optimum X shortcut utility, configuration information, a VBS script to enumerate and delete files, and a VBS script for pop-up message boxes (Fabian, 2016). As NW.js applications are packaged with and run in a stripped-down browser window, the malware initially appears to actually launch a version of Chrome.
            The power of the malware comes from NW.js, which was previously named Node-WebKit and is based on the open source Chromium browser project and the Node.js scripting language. It combines the ability of Node.js modules to develop powerful JavaScript event driven web servers and a stripped down version of Chromium to create standalone desktop applications based on JavaScript source code.  NW.js essentially creates its own self-contained web server and browser to run the JavaScript.  The fact that NW.js contains its own interpreter and browser accounts for the size of the malware.  NW.js allows web developers to turn their applications easily into standalone desktop applications (NW.js Documentation, 2016).
            The initial fear of Ransom32 was that it was browser-based JavaScript ransomware, which could possibly encrypt your hard drive contents from downloading a web page from a malicious web server.  Based on the above research, Ransom32 is, in fact, another standalone desktop ransomware that is not designed to run from a webserver. However, Ransom32 does show an evolution in the use of JavaScript in malware as ransomware and shows potential to be cross operating system compatible thanks to its use of NW.js.

3.            Client JavaScript Threat Vectors and Behaviors

3.1.      JavaScript interpreted in an operating system

Both Windows and Macintosh OS X have native command line JavaScript interpreters. The Windows interpreter is called Windows Script Host (WSH), and can run script files written using Microsoft’s implementation of JavaScript, called JScript. JavaScript files with a .js extension can be executed through WSH by double-clicking on the icon of the file or by running the file from the command line. WSH is also able to run VBScript code and has access to the ActiveX, the .NET framework, which allows it to directly interact with the Windows operating system and the local filesystem in a way not possible in many JavaScript interpreters (Wikipedia, 2016).
In OS X, the command line interpreter is called JavaScriptCore (JSC), which is the built-in JavaScript engine for WebKit and is used in the Safari browser provided with OS X (WebKit, 2014). In OS X, JavaScript can be run from the command line, but JSC is not in the default path, so the full path (/System/Library/Frameworks/JavaScriptCore.framework/Versions/Current/Resources/JSC) must be specified in order to run a script. The JSC interpreter is subject to the same limitations as a traditional web browser and does not appear to have any greater ability to directly access the file system. It cannot be disabled or removed without causing serious problems in OS X (Graham-Cumming, 2013).

3.2.   JavaScript in a web browser

JavaScript is one of the three core technologies that run the World Wide Web (others being HTML and CSS), providing client-side scripting functions on a large majority of websites. When JavaScript is disabled, many websites will no longer function. Modern web browsers run within a sandbox that only allows limited access to the file system.  This only allows them to download files through the browser and not perform disk input/output. The HTML5 standard provides mechanisms for users to perform more direct file system access through the file open or save dialog boxes, but all of these are dependent on user interaction and cannot be directly scripted. JavaScript has frequently employed a variety of exploits such as buffer overflows or heap sprays to perform malicious activity and circumvent browser restrictions. In the past, this has mostly consisted of “drive-by downloads”, in which a script on a malicious or compromised web page causes the browser to download and execute malware.

3.3.   JavaScript in a PDF file

The Portable Document Format (PDF) is a highly flexible file format that allows nearly any kind of content imaginable, from pictures and video to scripts to entire executable files to be embedded within the PDF document. A number of scripting languages, including ActionScript, JavaScript and Flash are supported. This feature allows for features like form validation and other interactive elements, but also for the execution of malicious code. PDF documents can be read by a variety of programs, including PDF readers like Adobe Acrobat and most modern web browsers. Different PDF readers provide support for different sets of embedded content, so not all platforms will run embedded scripts.

3.4.   JavaScript packaged as a desktop application

As seen in the case of Ransom32, JavaScript can be packaged with its own interpreter, such as NW.js, and run as a standalone desktop application that does not rely on a compatible interpreter already being installed. This can occur either by compiling the JavaScript and the interpreter into a native executable file (PE/ELF) for the target system or by including an executable interpreter that runs the script. Through this packaging, the application can have access to additional system resources and is not limited by the browser.  NW.js provides functions not available in standard JavaScript that allow direct file system interaction. This allows JavaScript malware to move beyond the realm of downloading a second stage malware, and it can now perform the actual malicious functions, such as ransomware, data exfiltration, or command and control.

4.            Lab Methodology

4.1.      Lab Setup

            In order to simulate the defense of GIAC endpoint systems, VMware Fusion 8 virtual machines (VM’s) were set up running OS X 10.11 “El Capitan” and Windows 10, as they represent the most commonly used operating systems in the GIAC environment. The following software was installed in the VM’s for testing:
      Windows 10 version 1511
      Microsoft Edge 25.10586.0.0
      Microsoft Internet Explorer 11.0.10586
      Google Chrome 48.0.2564.97
      Mozilla Firefox 43.0
      Adobe Reader DC 2015.010.20056

      OS X 10.11 “El Capitan”
      Apple Safari 9.0.3      
      Google Chrome 48.0.2564.97
      Mozilla FireFox 43.0
      Adobe Reader DC 2015.010.20056

4.1.1.    Ransom32 Sample

In order to understand how the Ransom32 malware would function in the GIAC environment, a sample was located and downloaded from the Malwr open source malware analysis site. At the time we downloaded the sample, 27 of 54 antivirus products detected the malware, indicating that signatures had been developed since the original article was published. We then scanned the Ransom32 sample using the CylanceV heuristic file scanner. This tool uses mathematical models to characterize the behavior of executable files and assign them a numerical score between 1 (safe) and -1 (unsafe). Ransom32 received a score of -0.9.  This clearly indicated that it was malicious. As Cylance does not rely on signatures, the results we observed from this test would have been the same the first time Ransom32 was encountered.
The downloaded Ransom32 binary was examined within the VM, confirmed to be a self-extracting RAR archive, and opened using the 7-Zip archive utility. It contained files consistent with the existing reports on Ransom32. Chrome.exe, which appeared to be the main executable malware file, did not open as an archive, and no JavaScript files were found in its PE resources. In order to obtain copies of the embedded JavaScript files, the malware was detonated in a Windows XP malware VM and CaptureBat (which is incompatible with Windows 7 and later) was used to capture what appeared to be the NW.js package files extracted by the running malware to C:\Documents and Settings\user\local_settings\temp. It appears that many of the extracted files were open source libraries used by the malware to perform network communication, encryption or other functions. It also contained a binary file called binary.bin, which contained some readable strings including the ransom message and Bitcoin payment information. It appears that this file is possibly a snapshot file generated by the nwjc NW.js compiler, and is likely used as a code obfuscation technique.
When the Ransom32 sample was detonated in the Windows 10 test VM without Internet access, it did not appear to function as intended.  No files were encrypted, and the ransom message was not displayed. When connected to the Internet, it still did not appear to function, possibly because its command and control site was no longer active.  Ransom32 relies on receiving a public key from the C2 server with which to encrypt the victim’s files.

4.1.2.   Simulated Malware

The code obfuscation techniques employed by Ransom32 prevented the extraction of its malicious JavaScript code, so we could not attempt to run it on other platforms or with other interpreters. In order to create a simple, but a reasonably realistic test of JavaScript-based malware, we created a series of scripts to simulate the behavior of JavaScript ransomware. Each of the test scripts was designed to read a text file containing fortunes from the user’s desktop, ROT-13 encode the text, then overwrite the original file with the encoded fortunes. Due to the unique features available in ActiveX and NW.js, separate scripts were written to take advantage of their respective file access methods and actually overwrite the target file. For those cases in which a direct file access feature was not available, the HTML5 file input element was used to pass the target file to the script in order to simulate a situation in which an attacker was able to use an exploit to gain file system access that would ordinarily be prohibited.

4.1.3.   Native JavaScript Interpreters

            In order to test the native JavaScript Interpreters provided by Windows and OS X, we attempted to run several test scripts from each operating system’s command line and GUI. As GIAC end users have no business need to run JavaScript natively and their user experience would not be degraded by its removal, we attempted to determine how to disable or remove JavaScript functionality.  The following was our process:
      OS X JavaScriptCore
      Run NW.js script
      Run JavaScript from HTML5 page
      Determine if JSC can safely be disabled or un-installed
      Windows Script Host
      ActiveX Script
      Determine if WSH can safely be disabled

4.1.4.   Web Browsers

            We tested each commonly used web browser in our environment using the HTML5 test script on both platforms and those running in Windows with the ActiveX test script.
      Apple Safari
      HTML5 Test
      Google Chrome
      ActiveX Test (Windows)
      HTML5 Test
      Microsoft Edge
      ActiveX Test
      HTML5 Test
      Microsoft Internet Explorer
      ActiveX Test (Windows)
      HTML5 Test
      Attempt to disable ActiveX
      Mozilla FireFox
      ActiveX Test (Windows)
      HTML5 Test

4.1.5.   PDF Readers

We first attempted to embed our test malware JavaScript in a PDF but were unsuccessful. We then used Didier Stevens' make-javascript-pdf.py utility to create a test PDF with an embedded JavaScript “hello world” script. We loaded the resulting PDF file into the test readers to determine if it would load the JavaScript.
      Adobe Reader DC
      Test script
      Disable JavaScript
      Apple Safari
      Test Script
      Google Chrome
      Test Script
      Disable in-browser loading of PDF’s
      Microsoft Edge
      Test Script
      OS X Preview
      Test Script

4.1.6.   NW.js Interpreter

Windows

The existence of Ransom32 proves that malicious JavaScript can be packaged as a Windows executable with NW.js. We wished to verify the ability to create a Windows executable from our NW.js test script that would run without the need to install any other software dependencies. In order to create our NW.js Windows executable, we created a .zip file containing our test script wrapped in HTML and a JSON package inventory. These files were merged with the NW.js interpreter into a Windows executable file that would run our script. This executable still required several .dll files and an NW.js resource file to run, which were included in the test directory to simulate that they had been placed there by a self-extracting archive, like the one used by Ransom32.
In order to prevent the execution of the malicious NW.js executable, and any other unrecognized program, we activated the Software Restriction Policy through the Local Group Policy Editor in the Windows control panel and set its default level to “Disallowed”.

OS X

As NW.js is designed to function the same way across platforms, we found it likely that malicious NW.js scripts that worked under Windows could be modified to run under OS X with minimal effort, as both would run under the same interpreter. In order to create an OS X app from our NW.js test script, all we changed in the script itself was the path to the user’s desktop folder where the target file was located and the direction of the slashes in the file path. OS X Apps are actually a directory structure containing files used in the application, so in order to create our NW.js OS X app, we simply opened the NW.js app’s directory structure and placed our script and package inventory files in the Contents/Resources/app.nw/ sub-folder inside the app.
In order to mitigate the threat of NW.js apps in OS X, we tested its Gatekeeper feature that is applied by default to programs downloaded from the Internet, as well as application whitelisting, available through the somewhat misleadingly named “Parental Controls” feature in OS X. In our test, the OS X Gatekeeper feature was set to only allow apps downloaded from the App Store, its most restrictive setting. The other technique we tested for OS X was to create a non-administrative user account, which in OS X is accomplished through the parental control settings.

4.2.      Lab Results

4.2.1.   Native JavaScript Interpreters

We tested the OS X JavaScriptCore(JSC) interpreter and determined that it would not run any of our test scripts from the command line, as it lacked the filesystem interfaces provided by ActiveX or NW.js and could not access the HTML5 user controlled file dialogs without running in a browser. JavaScript files could not be executed from the OS X GUI, but instead opened in a text editor or XCode, if installed. Based on these results, we conclude that JSC presents a limited threat to GIAC though we recognize the possibility that it could be exploited if a vulnerability is discovered.
The Windows Script Host, on the other hand, ran the ActiveX JavaScript test malware from both the command line and GUI with no additional prompts and successfully “encrypted” the target file. This suggests that ransomware could easily be written to take advantage of ActiveX and run under the WSH with no need for additional software dependencies. This would effectively bypass many host protection mechanisms, which do not detect malicious scripts well.
In order to mitigate this threat, we followed instructions found on Microsoft TechNet and edited the Windows Registry to disable the Windows Script Host. As expected, after the WSH was disabled, attempting to run the ActiveX test JavaScript failed with an error message indicating WSH was disabled and did not modify the target file. Disabling WSH did not appear to affect the ability to run any other programs on the system, including web browsers, which could still use JavaScript.

4.2.2.   Web Browsers

            Of all the browsers tested, only Microsoft Internet Explorer, running in Windows, was able to run the script containing ActiveX controls. Internet Explorer displayed a series of warning messages when executing the ActiveX test script.  However, if the user ignored or had disabled such warnings, the script could successfully modify the target file. Internet Explorer is a legacy browser included with Windows 10, but no longer the default. It has a history of vulnerability, due in part to its ability to use ActiveX. We believed that disabling ActiveX would prevent the malicious JavaScript from accessing the Filesystem since that was the mechanism relied upon in our script.  However, despite our best efforts to disable ActiveX, the script still ran successfully if the user clicked through the same two warning messages.  Therefore, we concluded that Internet Explorer represented too great a security vulnerability, and we recommend that it be removed from all Windows computers.
None of the other browsers tested were able to run ActiveX controls or directly access the filesystem. The simulated HTML5 ransomware was able to load in each of the web browsers except for FireFox in either Windows or OS X. FireFox did not run the script successfully, and gave no indication of why it had failed. We concluded that while there is a chance for the remaining browsers being exploited through JavaScript, disabling this functionality or using a plug-in like NoScript to block it would degrade the user experience too greatly to recommend this course of action.

4.2.3.   PDF Readers

            Of the PDF readers tested, only Adobe Reader and Google Chrome ran the embedded JavaScript from the test PDF file. Preview, Edge, and Safari loaded the PDF document but did not display the JavaScript-created message. We conclude that Preview, Edge, and Safari do not present a significant risk of JavaScript malware. After JavaScript was disabled through the Adobe Reader settings menu, it no longer ran the test JavaScript. The same behavior was observed on both the Windows and OS X VM’s (Naraine, 2009).
Google Chrome also ran JavaScript within PDF’s and did not have a way to disable this functionality without completely disabling JavaScript in the browser. Instead of disabling JavaScript, we decided to disable Chrome’s ability to open PDF’s by disabling the Chrome PDF viewer plugin that is enabled by default. After this was disabled, the PDF no longer opened natively in the browser, but rather downloaded to the local system.

4.2.4.   NW.js Interpreter

Windows

Our packaged NW.js executable ran successfully with only a brief flash of a blank window and successfully modified the target file. It did not trigger the User Account Control confirmation dialog box.
Following the implementation of Software Restriction Policies, the test executable was able to run but was not able to execute the script. It left behind an empty browser window and an intact fortunes file. All of the common programs installed on the test VM ran successfully after this setting was enabled. Thus, the likely user experience impact would be minimal.

OS X

            Much like its Windows relative, our packaged NW.js OS X app ran successfully with only a brief flash of a blank window and successfully modified the target file. The user was not prompted for their administrative “sudo” credentials.
            When the Gatekeeper is set to only allow files downloaded from the App Store, OS X will refuse to open the file since it is not from an identified developer. However, if the user right clicks on the app and selects open, they will be given the option to run the app anyway. Once the user selects the option to run the file once, they will be able to run it again without a prompt or warning, regardless of the method used to launch it. This is caused by a special quarantine properties flag set on the file.  If the app is modified before running, for example by adding the app.nw folder containing our test script, it will show a warning that the app was downloaded from the Internet and an option to open it. Additionally, if the application was opened on one computer and copied to another, the Gatekeeper quarantine flag is not re-enabled.
We attempted to simulate the process that would likely be used by malware authors to create a malicious app prior to delivery by opening the NW.js app on our host MacBook first and inserting the test code.  Then we copied it to the test VM, and the app ran without a prompt in the test VM.  It is also possible to clear the Gatekeeper quarantine flag from the command line.
            When the app was tested in a non-administrative user account with the “Limit Applications on this Mac” option is selected, the test app refused to run without an administrator entering their credentials and authorizing it.

5.            Research of Endpoint Protection Products

When Ransom32 was first released, it was only detected by two antivirus solutions. It took weeks before the majority of antivirus companies had generated signatures for it.  This lag for antivirus signature development is typical for most new malware. Signatures also cannot detect “diskless” JavaScript exploits that run exclusively in a browser without installing on the host. Because traditional antivirus products were ineffective against this kind of malware, we sought to identify other solutions that could assist in preventing the exploitation of systems. GIAC Enterprises relies heavily on contractors using their own Internet access, so networking sandbox solutions such as FireEye were not considered. Several of the products that are focused on anti-exploit technology are Invincea Advanced Endpoint Protection, Bromium vSentry, and Spikes Security AirGap Enterprise.
Two of the technologies, Invincea Advanced Endpoint Protection, and Bromium vSentry, are application-level micro-virtualization technologies, a recent evolution in the information security industry. Invincea and Bromium appear to be the only two products of this kind currently on the market. These technologies run on the endpoint systems and work by isolating the threat from the actual operating system. Because of this isolation, patching and signature detection become less important. This is done by running certain applications in a virtual environment under the direction of a hypervisor. In particular, there is a virtualized file system, registry, and memory. The application virtualization technologies then use the existing applications to run inside a container on the hypervisor. This container is essentially a mini-virtual machine (or micro-VM as Bromium calls it). This gives the hypervisor control over what actually talks to the operating system and segregates out malware and exploits that infect the systems. The bonus to running the applications inside a micro-VM container is that the hypervisor can observe and record all of the behavior of the application. When malware executes inside the micro-VM, it can be quickly identified, and all of the activities can be tracked to include indicators of compromise and intent of the malware. Once the container is closed, the virtual environment and any potential infections cease to exist, which remediates the threat. This greatly eliminates damage to endpoints; however, there may still be a threat that some information could have been leaked.
Bromium’s vSentry product is an endpoint software solution in which user-space applications, especially Internet Explorer, run inside a micro-VM. Bromium ensures all vulnerable user tasks such as visiting a website, opening a document, or accessing a USB drive are executed inside the micro-VM. Whenever an isolated task attempts to access files, networks, devices or the clipboard, the hardware interrupts execution and passes control to the micro-VM, which applies task-specific policies. Their Live Analysis and visualization technology (LAVA) provided introspection into the operation of the micro-VM in order to provide real-time intelligence on threats when they are executed inside. Since this operates above the micro-VM, it is immune from tampering, and can provide threat indicators and characterization, which speeds security analysts in determining the nature of threats and identifying indicators. Bromium technology is beginning to be integrated into Windows 10, and Bromium is hiring developers for the Macintosh OS X platform (Bromium, 2015).  Through a live demonstration, the technology was witnessed to block the execution of malware in one instance, and in another instance, it allowed for the execution of the malware in order to reveal how easily it was eradicated.
Invincea’s Advanced Endpoint Protection uses similar virtualization technology to separate web browsers and other applications from the operating system by running them from inside a virtualized environment from a kernel-level driver, which they simply call a container. Once again when the container is closed, the threat is eliminated and essentially self-remediated. This was witnessed in a recorded demonstration.  Invincea’s product also allows for the introspection of the threats. One difference in Invincea’s product is that they pair their application virtualization with a cloud-based analytic product called Cynomix, which researches unknown executables to determine if they are safe for an endpoint to run.
Both Invincea and Bromium’s products can be centrally managed, and both support Windows 10 (Invincea, 2015). This can reduce the risk for GIAC contractors using Windows. However, there is some concern about whether these products could be deployed successfully to contractor systems that are outside of the corporate network. Neither solution currently supports Macintosh OS X, the primary operating system in use by GIAC Enterprises’ employees.
A browser virtualization or “browser-as-a-service” product called Spikes Security AirGap Enterprise takes aim to remove the security risk posed by web browsers by moving them into the cloud. AirGap operates much like connecting to a system through a remote desktop tool then using the remote computer’s web browser.  AirGap creates a hardware-isolated virtual machine session for each browsing session. All user web requests are made through this virtual machine residing on a remote cloud server.  A lightweight client application then renders the browser session to the client over a secure connection using 256-bit encryption. The client has been optimized for both a high-quality video and audio experience.  Actions like copying, pasting, downloading, and printing are done through the client, and they are controllable through a security administration interface. AirGap provides clients for multiple platforms, including Windows and OS X. Because the hardware and the network are physically separated from the client, any attack would be directed to the virtualized browser session in the cloud, which is destroyed at the conclusion of the browsing session (Spikes Security, 2015).
The CEO, Brandon Spikes has stated, “We believe that the architecture and isolation capabilities of AirGap Enterprise provides the most secure, least complex, and highest performance solution to the browser malware problem.”  AirGap aims to decrease deployment complexity of micro-virtualization solutions and physically remove the problem from one’s corporation.  AirGap Enterprise appears to be an easy solution to protect web browser’s from malware threats; however, it doesn’t provide the protection outside of the browser to other user-space applications that the host based virtualized products like Bromium’s and Invincea’s products provide.

6.            Recommendations

            Based on our research, we are prepared to recommend a range of solutions to protect GIAC endpoint systems, both those used by employees and contractors, from JavaScript malware. These recommendations fall into three broad categories: removing or disabling vulnerable applications, preventing or containing malware execution and educating the end users. We believe that these measures will significantly reduce GIAC’s exposure to the threat of JavaScript malware, and many of our recommendations will help to improve GIAC’s overall security posture.

6.1.      Remove/Disable Vulnerable Applications/Features

            While all applications have some risk of exploitation, we have identified several applications for which we believe the risk outweighs the benefit provided by the software. We, therefore, recommend that the following software or features be removed from all GIAC systems. In the case of GIAC employee computers, we recommend that the applicable settings be configured in the baseline OS X images deployed on employee MacBook’s. In the case of contractors running Windows, we recommend that guidance and instructions to implement the requested changes be provided to each contractor, with the understanding that since they are using their own personal computers, we cannot enforce these requirements.

6.1.1.   Disable Windows Script Host

            On Windows systems, we recommend that the Windows Script Host be disabled by modifying the Windows registry to disable the service. As there is no centralized mechanism to make or enforce such changes to our contractors’ systems, we recommend providing a registry file that will set the appropriate values to each contractor running Windows on their endpoint system and requesting they install it.

6.1.2.   Remove Internet Explorer

            We recommend that our contractors remove Internet Explorer from their Windows systems.  We can see no reason to recommend our contractors keep it installed given the facts that: (a) Internet Explorer is based on older technology; (b) it contains a number of security flaws (none the least of which is its support for ActiveX); (c) it is being gradually phased out of Windows in favor of the new Edge browser; and (d) it has no features that can not be provided by other browsers.  We recommend providing contractors or employees running Windows with instructions to remove Internet Explorer from their systems and request they follow them. We also recommend disallowing Internet Explorer from accessing the website where contractors submit their fortunes to further encourage their compliance.

6.1.3.   Disable JavaScript in Adobe Reader

            Adobe Reader is the most common application for opening PDF files, and is notorious for its many security vulnerabilities discovered over the years. While modern versions run in a sandboxed environment with reduced access to the filesystem, we believe that allowing JavaScript to run in Adobe Reader presents an unnecessary risk for exploitation. Therefore, we recommend that JavaScript should be disabled in Adobe Reader on all end user systems, both Windows and OS X.

6.1.4.   Disable Google Chrome PDF Reader

While it is potentially preferable to open PDF’s in Chrome rather than an external viewer such as Adobe Reader, the lack of granular controls to disable PDF JavaScript in Chrome (without disabling all JavaScript in the browser) leads us to conclude that it is best to disable the Chrome PDF reader plugin. At the same time, we recommend that the Chrome Flash Player plugin be disabled due to its own history of security vulnerabilities.

6.2.      Prevent/Contain Malware Execution

            The next category of recommendations consists of products that will help prevent untrusted, potentially malicious applications from being executed or limit their ability to affect the system if they are executed.

6.2.1.   OS X Application Whitelisting

            While we evaluated two possible solutions for preventing malicious or untrusted code execution in OS X, our research indicated the Gatekeeper functionality included in OS X relied on the presence of an extended file attribute that could too easily be removed or bypassed either by the end user or a malicious actor. Instead, we believe that the “Parental Controls” feature that OS X uses to manage non-privileged user accounts will provide better protection. When the “Limit Applications on this Mac” option is selected, only the specified applications are allowed to run under the specified account. Only an administrator can modify the list of approved applications. Our testing confirmed that this was successful in preventing NW.js from running under the non-privileged user account. We conclude that this is the most effective way of preventing NW.js apps from running on OS X and propose that these restrictions be implemented on all employee MacBook’s when they are provisioned and enabled on those already deployed using Casper Suite. The same guidance and instructions should be provided to GIAC contractors using OS X.

6.2.2.   Windows Application Whitelisting

While we have found Windows application whitelisting through Software Restriction Policies to be effective in preventing the execution of malicious code, we do not see this as an ideal solution, as it relies on users to apply the correct security settings in a control panel menu most users do not regularly access. An alternative solution that would likely prove more effective and easier to manage is an application micro-virtualization solution, which is discussed below.

6.2.3.   Windows Application Micro-Virtualization

            Application Micro-Virtualization technology appears to be on the cutting edge of current anti-exploit technology with its ability to detect, prevent, and eradicate malware in near-real time.  The two product demonstrations of Invincea’s Advanced Endpoint Protection and Bromium’s vSentry both appear to be similar in their effectiveness on Windows systems.  While both will work with Windows 10 systems, they have yet to release products for Macintosh OS X.  Thus, these systems would only be effective for some of GIAC’s contractors.  Further, due to the lack of centralized management of GIAC’s contractors, the feasibility of deploying this solution to our contractors will have to be tested and evaluated.  These technologies need to be reviewed and tested in a side-by-side environment to determine which solution would be feasible and desirable (if at all) for deployment to contractors at GIAC Enterprises.

6.2.4.   Browser-as-a-Service

            Due to the current lack of support for Macintosh OS X systems for micro-virtualization technologies, a secondary, more scalable solution, Spikes Security AirGap Enterprise, is recommended.  AirGap Enterprise supports both Windows 10 and OS X.  AirGap Enterprise is essentially a browser-as-a-service, and the web browsing conducted in remote virtual machines in a way that is similar to micro-virtualization products.  This platform is highly secure since the browser actually runs on a remote server in the cloud and is delivered to the client through a remote desktop-like gateway. It is recommended to deploy the client on all Macintosh OS X systems in the enterprise.  It is also recommended to be offered for use by contractors and to be required for their connection to the GIAC Enterprises web portal.

6.3.      End-User Training

            The most critical component of protecting the endpoint always has been and likely always will be the user (Ponemon, 2015). Cyber security tends to be an arms race in which security professionals and hackers are constantly trying to counter each other's latest moves and countermoves. If end users know to avoid taking risky actions such as clicking on unknown email attachments and circumventing security controls, it will reduce the opportunity for attackers to introduce malicious software into the environment. Technical controls are still required to mitigate those threats that enter the environment through exploits or users’ mistakes. In an enterprise that relies as heavily on independent contractors as GIAC, user awareness training becomes even more critical, as many of the endpoint systems exist outside GIAC’s direct control.
            We recommend that GIAC continue to provide ongoing security awareness training to its employees and include information in that training about the threat from JavaScript malware, methods to defend against it and the reasons for the steps GIAC has taken to mitigate JavaScript threats. We also recommend that contractors be provided with similar training, but with additional focus on steps that they can take to protect their own endpoint systems, as this is their responsibility. We also recommend providing job aid reference material that contractors can refer to when configuring their computers.

7.            Conclusion

            While JavaScript has long posed a threat to endpoint systems, recent developments, like the NW.js framework that allows both for easy cross-platform development and the use of JavaScript for more general purpose scripting tasks with full file system access, increase the level of threat from JavaScript malware. These developments also increase the likelihood that malware authors will target other platforms such as OS X and Linux and lowers the barrier to entry for creating malware targeting these platforms. As GIAC primarily uses OS X for its employee endpoint systems, this increases the threat of malware successfully targeting our endpoint systems.
In order to understand the scope of the threat and likely attack vectors that could be used to target GIAC using JavaScript malware; we conducted a series of tests using simulated JavaScript ransomware, targeting Windows 10 and Mac OS X systems. Based on these tests, we concluded that the greatest vulnerabilities involved the Windows Script Host and ActiveX on Windows systems and NW.js on both platforms. We also identified other possible JavaScript vulnerabilities in the Adobe Reader and Google Chrome that we recommended closing to improve our overall security posture.
Based on this research, we have offered a series of recommendations to improve the security of our endpoint systems, both for our employees using systems managed by GIAC and our contractors using self-maintained systems. These recommendations represent a multi-tiered approach to security and include disabling the Windows Script Host and Microsoft Internet Explorer on Windows endpoint systems, disabling JavaScript in Adobe Reader and disabling the PDF Reader in Google Chrome. We also recommend the use of application whitelisting on both platforms, through the use of Software Restriction Policies in Windows and the Parental Controls in OS X. We also recommend further investigation into the use of an application micro-virtualization product such as Bromium or Invincea on Windows endpoints, and the use of a cloud-based browser-as-a-service solution such as AirGap Enterprise for all endpoint systems. By implementing these recommendations, we believe that we can significantly reduce the risk to the GIAC enterprise from JavaScript malware.
References

Abrams, Lawrence. (2016, January 3). Ransom32 is the first Ransomware written in JavaScript. Bleeping Computer. Retrieved from: http://www.bleepingcomputer.com/news/security/ransom32-is-the-first-ransomware-written-in-javascript/.
Fabian. (2016, January 1). Meet Ransom32: The first JavaScript ransomware. Emisoft Blog. Retrieved from: http://blog.emsisoft.com/2016/01/01/meet-ransom32-the-first-javascript-ransomware/.
Storm, Darlene. (2016, January 4). Ransom32: First-of-its-kind JavaScript-based ransomware spotted in the wild. Computerworld. Retrieved from: http://www.computerworld.com/article/3018972/security/ransom32-first-of-its-kind-javascript-based-ransomware-spotted-in-the-wild.html.
Ponemon Institute. (2015, January). 2015 State of the Endpoint Report: User-Centric Risk. http://www.ponemon.org/local/upload/file/2015%20State%20of%20Endpoint%20Risk%20FINAL.pdf.
Graham-Cumming, John. (2013, February 6). How to fix a corrupted JavaScriptCore.framework on Mac OS X 10.7.5. jgc.org Blog. Retrieved from: http://blog.jgc.org/2013/02/how-to-fix-corrupted.html.
Wikipedia. (2016). Windows Script Host. Wikipedia. Retrieved from: https://en.wikipedia.org/wiki/Windows_Script_Host.
Microsoft. (2016). Disabling Windows Script Host. Microsoft TechNet. Retrieved from: https://technet.microsoft.com/en-us/library/ee198684.aspx.
NW.js Documentation. (2016). NW.js Documentation. Retrieved from: http://nwjs.readthedocs.org/en/.
Webkit. (2014, July). JavaScriptCore. Webkit Documentation. Retrieved from: http://trac.webkit.org/wiki/JavaScriptCore.
Naraine, Ryan. (2009, April 28). Adobe: Turn Off JavaScript in PDF Reader. ZDNet. Retrieved from: http://www.zdnet.com/article/adobe-turn-off-javascript-in-pdf-reader/.
Invincea. (2015). Invincea Capabilities. Retrieved from: https://www.invincea.com/capabilities/contain/.
Bromium. (2015). Endpoint Security Products Overview. Retrieved from: http://www.bromium.com/products.html.
Spikes Security. (2015). AirGap™ The Technology That Makes Isla® a Powerful Web Malware Isolation System. Retrieved from: https://r.spikes.com/0.05.50/downloads/AirGap-Technology-White-Paper.pdf.
Direct Research
Didier Stevens’ make-pdf-javascript tool obtained from:  http://blog.didierstevens.com/programs/pdf-tools/.
In-person Bromium demonstration
Interview with Invincea sales rep via email
Appendix A:
Lab Notebook

1.            Lab Setup

In order to simulate the common GIAC endpoint systems to be defended, VMware Fusion 8 virtual machines (VM’s) were set up running OS X 10.11 “El Capitan” and Windows 10, as they represent the most commonly used operating systems in the GIAC environment. The following software was installed in the VM’s for testing:
Windows 10 version 1511
      Microsoft Edge 25.10586.0.0
      Microsoft Internet Explorer 11.0.10586
      Google Chrome 48.0.2564.97
      Mozilla Firefox 43.0
      Adobe Reader DC 2015.010.20056
OS X 10.11 “El Capitan”
      Apple Safari 9.0.3
      Google Chrome 48.0.2564.97
      Mozilla Firefox 43.0
      Adobe Reader DC 2015.010.20056

1.1.      Ransom32 Sample

1.1.1.   Malwr/Cuckoo Sandbox Analysis

A sample of the Ransom32 malware was located and downloaded from the Malwr open source malware analysis site. (https://malwr.com/analysis/Nzc4ZDQ4ZTk3MGFlNDJmY2IyNmZhMDY4Y2EwNjQ5Y2U/). The following cuckoo sandbox analysis report and comparative antivirus results were obtained from that site. This indicates a much higher rate of detection than initially reported, as AV vendors are obviously beginning to create signatures for Ransom32.
Analysis
CATEGORY
STARTED
COMPLETED
DURATION
FILE
2016-01-11 22:02:12
2016-01-11 22:04:47
155 seconds

File Details
FILE NAME
148458f5b9b2eb4f514faf03abce621f804ab60e2fe642870823a32456ed5482.bin
FILE SIZE
23530686 bytes
FILE TYPE
PE32 executable (GUI) Intel 80386, for MS Windows
MD5
09f21eefaf8f52496d4e8b06920fe6fa
SHA1
eda9e8c9eb6e1a6033b2a197e09cd96e0601c70d
SHA256
148458f5b9b2eb4f514faf03abce621f804ab60e2fe642870823a32456ed5482
SHA512
c655cc5e66800216bcc9c598478077b0159334ac74a178ec978af901ede9c63c8f4d8291a651546139e9113a14a55aced350301f14e63890647a3d2facfe4ac9
CRC32
2E0B8347
SSDEEP
393216:YMzt+wP9RBGBJ7+OOEcX7rT3ZPoulmNMNizNDK3E4JRPQ5mtGSTpUubW7uLXxXQV:bn0BJCOO9rrT3ZPoDNQipu3dJRoG9Tmr
YARA
None matched

Signatures

Screenshots

Hosts
No hosts contacted.
Domains
No domains contacted.

ANTIVIRUS
SIGNATURE
Bkav
W32.KakarazekA.Trojan
MicroWorld-eScan
Trojan.Ransom.ANL
nProtect
Clean
CMC
Clean
CAT-QuickHeal
Ransom.Ransom32.G8
ALYac
Clean
Malwarebytes
Trojan.Agent.PRA
VIPRE
Trojan.Win32.Generic!BT
K7AntiVirus
Riskware ( 0040eff71 )
BitDefender
Clean
K7GW
Riskware ( 0040eff71 )
TheHacker
Clean
NANO-Antivirus
Clean
Cyren
W32/Ransom.WPWK-0798
Symantec
Trojan.Ransomcrypt.Y
ESET-NOD32
Win32/Filecoder.NFR
TrendMicro-HouseCall
Ransom_.28452B59
Avast
Win32:Malware-gen
ClamAV
Clean
Kaspersky
Trojan-Ransom.JS.Ransom32.a
Alibaba
Clean
Agnitum
Clean
ViRobot
Clean
AegisLab
Clean
ByteHero
Clean
Rising
PE:Malware.Generic/QRS!1.9E2D [F]
Ad-Aware
Trojan.Ransom.ANL
Sophos
Troj/Ransom-BXH
Comodo
TrojWare.Win32.Ransom32.~I
F-Secure
Clean
DrWeb
Trojan.Ransom.326
Zillya
Clean
TrendMicro
Ransom_.28452B59
McAfee-GW-Edition
Clean
Emsisoft
Clean
F-Prot
Clean
Jiangmin
Clean
Antiy-AVL
Clean
Microsoft
Ransom:JS/Enrume.A
Arcabit
Clean
SUPERAntiSpyware
Clean
GData
Win32.Trojan-Ransom.Ransom32.B
AhnLab-V3
Clean
McAfee
Clean
AVware
Trojan.Win32.Generic!BT
VBA32
Clean
Baidu-International
Clean
Zoner
Clean
Tencent
Clean
Ikarus
Trojan-Ransom.Win32.Ransom32
Fortinet
W32/Agent.944A!tr
AVG
Downloader.Generic_c.AKPK
Panda
Trj/CI.A
Qihoo-360
HEUR/QVM41.1.Malware.Gen


1.1.2.   CylanceV Analysis

We tested the Ransom32 sample using the CylanceV heuristic file scanner. This tool uses mathematical models to characterize the behavior of executable files and assign them a numerical score between 1 (safe) and -1 (unsafe). As it does not rely on signatures, the results we observed from this test would have been the same the first time Ransom32 was encountered.

sha256 148458f5b9b2eb4f514faf03abce621f804ab60e2fe642870823a32456ed5482
score -0.90
filename C:\Users\sansforensics408\Downloads\ransom32.exe.bin
       Misc
o       CodepageLookupImports : This object imports functions used to look up the codepage (location) of a running system.
       Deception
o       DebugCheckImports : This object imports functions that would allow it to act like a debugger.
o       UsesCompression : This object seems to have portions of the code that appear to be compressed.
       Collection
o       OSInfoImports : This object imports functions that are used to gather information about the current operating system.
o       ProcessorInfoWMI : This object imports functions that can be used to determine details about the processor.
       Anomalies
o       AppendedData : This PE has some extra content appended to it, beyond the normal areas of the file.
o       RaiseExceptionImports : This object imports functions used to raise exceptions within a program.
       Destruction
o       SeRestorePrivilege : This PE might attempt to change or delete files to which it has not been granted access.
o       FileDirDeleteImports : This PE imports functions that can be used to delete Files or Directories.
o       TerminateProcessImports : This object imports functions that can be used to stop a running process.

1.1.3.                  Static Analysis

The downloaded Ransom32 binary was confirmed to be a self-extracting RAR archive and opened using the 7-Zip archive utility.

Filename: /Users/user/Desktop/ransom32.exe.bin
Size (bytes): 23530686
MD5: 09f21eefaf8f52496d4e8b06920fe6fa
SHA1: eda9e8c9eb6e1a6033b2a197e09cd96e0601c70d
SSDeep: 393216:YMzt+wP9RBGBJ7+OOEcX7rT3ZPoulmNMNizNDK3E4JRPQ5mtGSTpUubW7uLXxXQV:bn0BJCOO9rrT3ZPoDNQipu3dJRoG9Tmr (Ver 1.1)
Filetype: PE32 executable (GUI) Intel 80386, for MS Windows, RAR self-extracting archive
File Modification Date/Time: 2016-01-12 09:33:58
PE Time Stamp: 2015-11-14 04:35:42
File Type: Win32 EXE
Subsystem: Windows GUI
imphash: 1e4543b94f902fb1e062932841a7f90c
Section Hashes (MD5):
          .data: (rw.) 97b33de4f6c0dd8a60e7648d167a1c55
         .rdata: (r..) a1eb448998f7794f371a9e2d09bf3b88
          .text: (r.x) 06c96275e6ee6660732df41e3f60e7fe
          .rsrc: (r..) 3feab3c701c2822c84134921e80103fc
pehash: ce67f30ac060088677d6bf3be131cd75d421dc13
Resource Section Hashes (SHA256):
      RT_BITMAP: 690c938562399f89ad78e3fde2a7edaee8ddf2fafef987a7b37e577a8f6126ea (data)
        RT_ICON: 9f7ad16729621f0dc663ff20dd634faf72a3e08b228d3fe6c5413a737ca4f16c (data)
        RT_ICON: 2a26a1ca366df9b7c9c075fdf4e8334168b2d59a0679e7af0682a5693662d817 (dBase IV DBT of @.DBF, block length 1024, next free block index 40, next free block 16382456, next used block 16317695)
        RT_ICON: aa7e80de794c4db5f03c047748c9d5db710f613599166845859cddeec0141c24 (data)
        RT_ICON: d620f4dabce8419b77e351bdf50febf983e7ac93ce03f10ea80277f651ca006e (GLS_BINARY_LSB_FIRST)
        RT_ICON: d8feb0af2788aeb1ad7dfa86d93f6bafece60b9a587c817f8bbd1bd299719050 (PNG image data, 256 x 256, 8-bit/color RGBA, non-interlaced)
        RT_ICON: 3be08108c51dcf3cf016dd804c1f76244c5745391fdcede1a0e92c2296baab3b (dBase IV DBT, blocks size 0, block length 2048, next free block index 40, next free block 0, next used block 0)
        RT_ICON: f86ed611affa8667b4bbdc0c189130403545246e3d74a4234db99f30bbdb2f2b (data)
        RT_ICON: 0b5ea589ef12e12ca87b453fdf986cba4917df933c5f8d9fbcbb1e0edc4f2514 (data)
        RT_ICON: 51afc9abba70aca232b135c911f209c0104bb617d8e78bd7a8261654e277cc7d (data)
        RT_ICON: 77684125b016dbc237f34124f1b7183ab02fc4380d08e13b46cae03517bcb914 (GLS_BINARY_LSB_FIRST)
      RT_DIALOG: 887347f27d903f6652ba35c3dfae297c23435755a63e02a80259ee6dd0b8af86 (data)
      RT_DIALOG: 2e11a1ed4f812e37fdb32a1310cdcca802c46497c27e33ab66ac127345463d31 (data)
      RT_DIALOG: 44e6a8daef1ac762f8016fc4c8aec52bad42f589b6d8a25d430a619610dd0028 (data)
      RT_DIALOG: 30358e9c494ca9d125b34ccb93a2d8f1237042904f6fcecc2f5ca9a83b7dba9d (data)
      RT_DIALOG: a1141852e6fb28826de51733ee35fbfdcf74dd8eb7f73049c7c7ad6c21d0cb33 (data)
      RT_DIALOG: 0f47dbda4a6e61d3288f63f249d25ab3f6e1fe497879a782d3eb1cd3922f3f4e (data)
      RT_STRING: 450b4d82a86dba50acea995d6356e0174a242081f2c2438f6f88c29038f7097d (data)
      RT_STRING: 89051dca472bd5ebb7b344c05150755b6e3d32cb0dffea086c04186820b188d2 (data)
      RT_STRING: 4b330444367ebff69a042f9aaa930485c02a02e7efdad56db24cb2b76dc8f134 (data)
      RT_STRING: 1e87eca343221966ecd9472109f3baf9081c821e3f4e905aa34eb8bce73af4e7 (Hitachi SH big-endian COFF object, not stripped)
      RT_STRING: 06b2bd666ed1afbbfc9914b94d703087c18248c5fe28dead42e42f22c3984c5e (data)
      RT_STRING: d5755fffe2a9a4baf3593b8fba9a029b23bcc08e77c8d98e07b93baee6b9e6de (data)
      RT_STRING: a71a1445d83285856c39bf2f0caa19e88c9be65f0178a6878f321a925a21f97c (data)
      RT_STRING: 71966cf60a28c1cdde4196d7909347e3f66661546af21edbacb15c7116944832 (data)
      RT_STRING: f63fabe3ed749afb7b1719755170afe965f37e216834adf90dec051811afe657 (data)
  RT_GROUP_ICON: 1edb49c60b2498f54831510d42c4007429b64a07810937e64a17acd841fdff58 (MS Windows icon resource - 10 icons, 48x48)
    RT_MANIFEST: 1b7b67e5d8927449d8f7be80a0e5ba5f03d25670035027c0cb71abce27da6810 (XML 1.0 document, ASCII text, with CRLF line terminators)


Chrome.exe, which appeared to the main executable malware file, did not open as an archive and no JavaScript files were found in its PE resources.

Filename: /Users/user/Desktop/ransom32.exe.bin
Size (bytes): 23530686
MD5: 09f21eefaf8f52496d4e8b06920fe6fa
SHA1: eda9e8c9eb6e1a6033b2a197e09cd96e0601c70d
SSDeep: 393216:YMzt+wP9RBGBJ7+OOEcX7rT3ZPoulmNMNizNDK3E4JRPQ5mtGSTpUubW7uLXxXQV:bn0BJCOO9rrT3ZPoDNQipu3dJRoG9Tmr (Ver 1.1)
Filetype: PE32 executable (GUI) Intel 80386, for MS Windows, RAR self-extracting archive
File Modification Date/Time: 2016-01-12 09:33:58
PE Time Stamp: 2015-11-14 04:35:42
File Type: Win32 EXE
Subsystem: Windows GUI
imphash: 1e4543b94f902fb1e062932841a7f90c
Section Hashes (MD5):
          .data: (rw.) 97b33de4f6c0dd8a60e7648d167a1c55
         .rdata: (r..) a1eb448998f7794f371a9e2d09bf3b88
          .text: (r.x) 06c96275e6ee6660732df41e3f60e7fe
          .rsrc: (r..) 3feab3c701c2822c84134921e80103fc
pehash: ce67f30ac060088677d6bf3be131cd75d421dc13
Resource Section Hashes (SHA256):
      RT_BITMAP: 690c938562399f89ad78e3fde2a7edaee8ddf2fafef987a7b37e577a8f6126ea (data)
        RT_ICON: 9f7ad16729621f0dc663ff20dd634faf72a3e08b228d3fe6c5413a737ca4f16c (data)
        RT_ICON: 2a26a1ca366df9b7c9c075fdf4e8334168b2d59a0679e7af0682a5693662d817 (dBase IV DBT of @.DBF, block length 1024, next free block index 40, next free block 16382456, next used block 16317695)
        RT_ICON: aa7e80de794c4db5f03c047748c9d5db710f613599166845859cddeec0141c24 (data)
        RT_ICON: d620f4dabce8419b77e351bdf50febf983e7ac93ce03f10ea80277f651ca006e (GLS_BINARY_LSB_FIRST)
        RT_ICON: d8feb0af2788aeb1ad7dfa86d93f6bafece60b9a587c817f8bbd1bd299719050 (PNG image data, 256 x 256, 8-bit/color RGBA, non-interlaced)
        RT_ICON: 3be08108c51dcf3cf016dd804c1f76244c5745391fdcede1a0e92c2296baab3b (dBase IV DBT, blocks size 0, block length 2048, next free block index 40, next free block 0, next used block 0)
        RT_ICON: f86ed611affa8667b4bbdc0c189130403545246e3d74a4234db99f30bbdb2f2b (data)
        RT_ICON: 0b5ea589ef12e12ca87b453fdf986cba4917df933c5f8d9fbcbb1e0edc4f2514 (data)
        RT_ICON: 51afc9abba70aca232b135c911f209c0104bb617d8e78bd7a8261654e277cc7d (data)
        RT_ICON: 77684125b016dbc237f34124f1b7183ab02fc4380d08e13b46cae03517bcb914 (GLS_BINARY_LSB_FIRST)
      RT_DIALOG: 887347f27d903f6652ba35c3dfae297c23435755a63e02a80259ee6dd0b8af86 (data)
      RT_DIALOG: 2e11a1ed4f812e37fdb32a1310cdcca802c46497c27e33ab66ac127345463d31 (data)
      RT_DIALOG: 44e6a8daef1ac762f8016fc4c8aec52bad42f589b6d8a25d430a619610dd0028 (data)
      RT_DIALOG: 30358e9c494ca9d125b34ccb93a2d8f1237042904f6fcecc2f5ca9a83b7dba9d (data)
      RT_DIALOG: a1141852e6fb28826de51733ee35fbfdcf74dd8eb7f73049c7c7ad6c21d0cb33 (data)
      RT_DIALOG: 0f47dbda4a6e61d3288f63f249d25ab3f6e1fe497879a782d3eb1cd3922f3f4e (data)
      RT_STRING: 450b4d82a86dba50acea995d6356e0174a242081f2c2438f6f88c29038f7097d (data)
      RT_STRING: 89051dca472bd5ebb7b344c05150755b6e3d32cb0dffea086c04186820b188d2 (data)
      RT_STRING: 4b330444367ebff69a042f9aaa930485c02a02e7efdad56db24cb2b76dc8f134 (data)
      RT_STRING: 1e87eca343221966ecd9472109f3baf9081c821e3f4e905aa34eb8bce73af4e7 (Hitachi SH big-endian COFF object, not stripped)
      RT_STRING: 06b2bd666ed1afbbfc9914b94d703087c18248c5fe28dead42e42f22c3984c5e (data)
      RT_STRING: d5755fffe2a9a4baf3593b8fba9a029b23bcc08e77c8d98e07b93baee6b9e6de (data)
      RT_STRING: a71a1445d83285856c39bf2f0caa19e88c9be65f0178a6878f321a925a21f97c (data)
      RT_STRING: 71966cf60a28c1cdde4196d7909347e3f66661546af21edbacb15c7116944832 (data)
      RT_STRING: f63fabe3ed749afb7b1719755170afe965f37e216834adf90dec051811afe657 (data)
  RT_GROUP_ICON: 1edb49c60b2498f54831510d42c4007429b64a07810937e64a17acd841fdff58 (MS Windows icon resource - 10 icons, 48x48)
    RT_MANIFEST: 1b7b67e5d8927449d8f7be80a0e5ba5f03d25670035027c0cb71abce27da6810 (XML 1.0 document, ASCII text, with CRLF line terminators)

1.1.4.                  Behavioral Analysis

Ransom32 was detonated in a malware analysis VM without Internet access and did not appear to function as intended, as no files were encrypted and the ransom message was not displayed. When connected to the Internet, it still did not appear to function, possibly as a result of its command and control site no longer being active, since Ransom32 relies on receiving a public key from the C2 server with which to encrypt the victim’s files.

The malware was again detonated in a Windows XP malware VM and CaptureBat (which is incompatible with Windows 7 and later) was used to capture what appeared to be the nw.js package files extracted from the Ransom32 malware. The following files and directories were extracted by the running malware to C:\Documents and Settings\user\local_settings\temp. It appears that many of the extracted files were open source libraries used by the malware to perform network communication, encryption or other functions.
      index.html
      Contains a simple script to decode and run binary.bin
      package.json
      Nw.js package definition
      binary.bin
      Binary file with some readable strings including the ransom message and Bitcoin payment information
      Possibly a snapshot file generated by nwjc (ref. http://nwjs.readthedocs.org/en/tmp/References/Window/#winevalnwbinframe-path)
      node_modules\
      cpr\
      Utility that removes directories if they exist
      https://travis-ci.org/davglass/cpr/
      minimatch\
      Utility for regular expression building
      https://travis-ci.org/isaacs/minimatch
      node-rsa\
      Node.js RSA library
      socks5\
      Node.js SOCKS5 proxy library

1.2.      Simulated Malware

The code obfuscation techniques employed by Ransom32 prevented the extraction of its malicious JavaScript code, so we could not attempt to run it on other platforms or with other interpreters. In order to create a simple, but reasonably realistic test of JavaScript-based malware, we created a series of scripts to simulate the behavior of JavaScript ransomware. Each of the test scripts was designed to read the file Fortunes.txt from the user’s desktop, ROT-13 encode it, then overwrite the original file with the encoded fortunes. Due to the unique features available in ActiveX and nw.js, separate scripts were written to take advantage of their respective file access methods and actually overwrite the target file.

For those cases that in which a convenient vulnerability feature was not available, the HTML5 file input element was used to pass the target file to the script in order to simulate a situation in which an attacker was able to use an exploit to gain file system access that would ordinarily be prohibited, without actually having to locate such an exploit.

HTML Wrapper

<html>
  <input type="file" id="fileInput" name="files" value=".\Fortunes.txt" multiple />
  <br>Original Text:<hr>
  <output id="fileOutput"></output><hr>
  Encrypted Text:<hr>
  <output id="encOutput"></output>
  <script src="html5.js"></script> 
</html>

Fortunes.txt

You will be pwned today.
These aren't the droids you're looking for.
Eagles may soar, but weasels aren't sucked into jet engines.
No TV and no beer make Homer go crazy!
There is a simple solution to every complex problem. It is invariably wrong.
Artificial Intelligence is no match for Natural Stupidity.
Beware of JavaScript.
There Is an Exception to Every Rule, and Most People Think They Are It.
Let the Wookie win.

1.2.1.   “Nerf” Ransomware – ActiveX

function rot13(str) {
  return str.replace(/[a-zA-Z]/g, function(chr) {
    var start = chr <= 'Z' ? 65 : 97;
    return String.fromCharCode(start + (chr.charCodeAt(0) - start + 13) % 26);
  });
}

rline = new Array();

var objFSO = new ActiveXObject("Scripting.FileSystemObject");
var readFile = objFSO.OpenTextFile("Fortunes.txt");
var count = 0;

while( !readFile.AtEndOfStream ){
   rline[count] = rot13(readFile.ReadLine());
   count++;
}

var writeFile = objFSO.OpenTextFile("Fortunes.txt", 2);

for (i = 0; i < rline.length; ++i){
writeFile.WriteLine(rline[i]);
}

1.2.2.   “Nerf” Ransomware – nw.js

<!DOCTYPE html>
 <html>
   <script>
   var fs = require("fs");
   var gui = require('nw.gui');

   function rot13(str) {
            return str.replace(/[a-zA-Z]/g, function(chr) {
                        var start = chr <= 'Z' ? 65 : 97;
                        return String.fromCharCode(start + (chr.charCodeAt(0) - start + 13) % 26);
            });
   }

   var content;
   var App = {
     FILE: "/Users/dave/Desktop/Fortunes.txt",

     el: document.getElementById("content"),

     init: function () {
       this.load();
       this.save();
     },

     load: function () {
       if (fs.existsSync(this.FILE)) {
         content = fs.readFileSync(this.FILE, "utf8");
       }
     },

     save: function () {
       var encrypted = rot13(content);
       fs.writeFileSync(this.FILE, encrypted, "utf8");
       gui.App.quit();
     }
   };

   App.init();

   </script>
 </html>

1.2.3.   Simulated Ransomware – HTML5

function rot13(str) {
  return str.replace(/[a-zA-Z]/g, function(chr) {
    var start = chr <= 'Z' ? 65 : 97;
    return String.fromCharCode(start + (chr.charCodeAt(0) - start + 13) % 26);
  });
}

window.onload = function() {
var fileInput = document.getElementById('fileInput');
            var fileOutput = document.getElementById('fileOutput');

            fileInput.addEventListener('change', function(e) {
                        var file = fileInput.files[0];
                        var textType = /text.*/;

                        if (file.type.match(textType)) {
                                    var reader = new FileReader();

                                    reader.onload = function(e) {
                                                fileOutput.innerText = reader.result;
                                                encOutput.innerText = rot13(reader.result);
                                    }

                                    reader.readAsText(file);    
                        } else {
                                    fileOutput.innerText = "File not supported!"
                        }
            });
}

2.            Vulnerability Tests

2.1.      Native JavaScript Interpreters

2.1.1.   Windows Script Host

Problem:

The Windows Script Host will run JavaScript files natively from the Windows GUI and command line. ActiveX gives WSH the ability to directly interact with the filesystem, as demonstrated by our test in which Pwn_ActiveX.js ran with no prompt and successfully encrypted the target file when the script was double clicked. It behaved the same when called from the command line.




Thesis:

In order to prevent the execution of malicious JavaScript, we proposed to disable the Windows Script Host via the registry. This should prevent the native execution of JavaScript (and VBScript) files on Windows systems.

Finding:

We followed the instructions for disabling Windows Script Host found at

We used the Windows Registry Editor to create the
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows Script Host\Settings\Enabled
(REG_DWORD) registry key and set its value to 0. This registry key does not exist by default and had to be created.


As expected, after the Windows Script Host was disabled in the Registry, attempting to run the Pwn_ActiveX.js JavaScript failed with the following error message and did not modify the target file.


2.1.2.   OS X JavaScriptCore(JSC)

Problem:

OS X includes JavaScriptCore (JSC), a command line JavaScript interpreter based on the WebKit engine. It is located at /System/Library/Frameworks/JavaScriptCore.framework/Versions/Current/Resources/jsc, which is not in the default path and can be run without administrative privileges. We attempted to directly access the filesystem through JSC but were unsuccessful.

Thesis:

While not as readily exploitable as the Windows Script Host, JSC still poses some threat of malicious code execution.

Finding:

There does not appear to be a way to safely disable or remove the JSC from OS X without breaking its web browsing ability and the Preview utility. Removing it requires serious abuse of the OS X filesystem permissions, as it is a system resource that cannot be deleted, even by root. We conclude that this utility presents no greater risk than running the other WebKit-based browsers on OS X.

2.2.      Windows Browsers

2.2.1.   Chrome

Problem:

The Chrome Browser is one of the more popular browsers in current use and, like all browsers presents some risk for JavaScript exploitation. We attempted to determine if the browser would execute both the ActiveX and HTML5 test scripts.


Thesis:

We believed that Chrome would not execute the ActiveX script, but would run the HTML5 test that required user interaction.

Finding:

As expected, Chrome would not run the ActiveX script did run the HTML5 script. We conclude that unless a potential exploit allows a malicious JavaScript to break out of the browser sandbox, it presents a relatively low risk. JavaScript in Chrome can only access the file system through direct user interaction, and does not directly execute downloaded files.

 

2.2.2.   Edge

Problem:

The Edge Browser is the new default web browser in Microsoft Windows 10 and, like all browsers presents some risk for JavaScript exploitation. We attempted to determine if the browser would execute both the ActiveX and HTML5 test scripts.



Thesis:

We believed that Edge would not execute the ActiveX script, but would run the HTML5 test that required user interaction.

Finding:

As expected, Edge did not run the ActiveX script but did run the HTML5 script. We conclude that unless a potential exploit allows a malicious JavaScript to break out of the browser sandbox, it presents a relatively low risk. JavaScript in Chrome can only access the filesystem through direct user interaction, and does not directly execute downloaded files though they can be run from a dialog box within the browser after download. Chrome behaved identically in Windows and OS X.




2.2.3.   Firefox

Problem:

The Firefox Browser is one of the more popular browsers in current use and, like all browsers presents some risk for JavaScript exploitation. We attempted to determine if the browser would execute both the ActiveX and HTML5 test scripts.

Thesis:

We believed that Firefox would not execute the ActiveX script, but would run the HTML5 test that required user interaction.

Finding:

As expected, Firefox would not run the ActiveX script, however we discovered that the HTML5 test script also failed to run with no explanation. We conclude that unless a potential exploit allows a malicious JavaScript to break out of the browser sandbox, it presents a relatively low risk. JavaScript in Chrome can only access the file system through direct user interaction, and does not directly execute downloaded files. We are uncertain of why it did not properly execute our test script. Firefox behaved identically in Windows and OS X.



2.2.4.   Internet Explorer

Problem:

Internet Explorer is a legacy browser included with Windows 10, but no longer the default. It has a history of vulnerability due in part to its ability to use ActiveX. Our testing indicated that it would display a series of warnings when executing our Pwn_ActiveX.js script, but if the user ignored or had disabled such warnings, would successfully modify the target file.







Thesis:

We believed that by disabling ActiveX in Internet Explorer, it would prevent the malicious JavaScript from modifying the target file by disabling, ActiveX, which it was relying on for filesystem access.

Finding:

We discovered that, despite our best efforts to disable ActiveX in Internet Explorer, the script still ran successfully if the user clicked through the same two warning prompts.

2.2.5.   Safari


Problem:

The Safari Browser is the default browser in OS X and reasonably popular in Windows. Like all browsers, it presents some risk for JavaScript exploitation. We attempted to determine if the browser would execute both the ActiveX and HTML5 test scripts.

Thesis:

We believed that Safari would not execute the ActiveX script, but would run the HTML5 test that required user interaction.

Finding:

As expected, Safari would not run the ActiveX script did run the HTML5 script. We conclude that unless a potential exploit allows a malicious JavaScript to break out of the browser sandbox, it presents a relatively low risk. JavaScript in Chrome can only access the file system through direct user interaction, and does not directly execute downloaded files.

2.3.      PDF Readers

The PDF format allows a variety of objects to be embedded, including several kinds of scripts, one of which is JavaScript. A variety of programs on a modern computer can open PDF’s, including Adobe Reader, the OS X Preview application and the Microsoft Edge and Google Chrome browsers. We first attempted to embed our test malware JavaScript in a pdf but were unsuccessful. We then used Didier Stevens' make-javascript-pdf.py (http://blog.didierstevens.com/programs/pdf-tools/) to create a test pdf with an embedded JavaScript “hello world” script.

2.3.1.   Adobe Reader

Problem:

Adobe Reader is the most common application for opening PDF files and is notorious for the many security vulnerabilities discovered over the year. While modern versions run sandboxed with reduced access to the filesystem, we believe that allowing JavaScript to run in Adobe Reader presents an unnecessary risk for exploitation.

Thesis:

We anticipated that Adobe Reader would run JavaScript code, so we wished to disable this functionality and confirm that it would not run JavaScript.

Finding:

As expected, Adobe Reader DC, with default settings, ran the JavaScript test script. After JavaScript was disabled by unchecking the “Enable Acrobat JavaScript” box under the Edit > Preferences > JavaScript menu, Adobe Reader no longer ran the test JavaScript. The same behavior was observed on both the Windows and OS X VM’s.

 

 


2.3.2.   OS X Preview

Problem:

Preview is the default application for opening PDF files in OS X. We wished to evaluate its ability to run JavaScript to determine if it posed a threat of executing malicious JavaScript.

Thesis:

We propose to determine if Preview successfully runs JavaScript code and if so, disable this functionality.

Finding:

The JavaScript test code did not execute from within Preview, therefore, we concluded that it would not execute JavaScript code in a PDF and no further mitigation was necessary.


2.3.3.   Edge

Problem:

The Edge browser is the default application for opening PDF files in Windows 10. We wished to evaluate its ability to run JavaScript to determine if it posed a threat of executing malicious JavaScript.

Thesis:

We propose to determine if Edge successfully runs JavaScript code and if so, disable this functionality.

Finding:

The JavaScript test code did not execute from within Edge, therefore, we concluded that it would not execute JavaScript code in a PDF and no further mitigation was necessary.



2.3.4.   Safari
Problem:

The Safari web browser is capable of opening PDF files. We wished to evaluate its ability to run JavaScript to determine if it posed a threat of executing malicious JavaScript.

Thesis:

We propose to determine if Safari successfully runs JavaScript code and if so, disable this functionality.

Finding:

The JavaScript test code did not execute from within Safari, therefore, we concluded that it would not execute JavaScript code in a PDF and no further mitigation was necessary.



2.3.5.   Chrome
Problem:

Google Chrome is capable of opening PDF files in the browser, so we wished to evaluate its ability to run JavaScript to determine if it posed a threat of executing malicious JavaScript.

Thesis:

We propose to determine if Chrome successfully runs JavaScript code and if so, disable this functionality.

Finding:

With default settings, both the Windows and OS X versions of Chrome executed the JavaScript test code. After disabling the Chrome PDF viewer plugin that is enabled by default (and the Flash plugin just because this is always a good idea), the PDF no longer opened natively in the browser. Instead, it downloaded to the local system. While Chrome is an otherwise trusted application, the lack of granular controls to disable PDF JavaScript in Chrome without disabling all JavaScript in the browser lead to recommend this course of action.



2.4.      Nw.js Interpreter

Nw.js, the framework in which the Ransom32 malware is written, provides a way to write JavaScript code for a single interpreter and deploy it on multiple systems. I supports  Windows, OS X, and Linux. Nw.js also provides the ability to directly access the file system through its own interpreter, which is what allows Ransom32 to do its dirty work.

2.4.1.   Windows

Problem:

As has been demonstrated by the real-world example of Ransom32, nw.js applications can perform malicious actions on a Windows system.

Thesis:

We wished to verify the ability to create a Windows executable from our nw.js test script that would run without the need to install any other software dependencies. We then wished to find a method to prevent such programs from executing on the target computer.

In order to create our nw.js Windows executable, we followed the following procedure:

      Created .zip file containing index.html and package.json.
      Changed extension of .zip file to .nw
      Combine into Windows PE with the command 'copy /b nw.exe+app.nw pwn.exe'
      Still requires several nw.js .dll files and nw.pak in the same directory to run

In order to prevent the execution of the malicious nw.js executable, we activated the Software Restriction Policy using the following procedure:

      Open Local Group Policy Editor > Windows Settings > Security Settings > Software Restriction Policies
      Right click and select “New Software Restriction Policies”
      Right Click on “Security Levels”
      Right Click on “Disallowed”, select “Set as Default”

Finding:

Our packaged nw.js executable ran successfully with only a brief flash of a blank window and successfully modified the target file. It did not trigger the User Account Control confirmation dialog box.

Following the implementation of Software Restriction Policies, Pwn.exe was able to run but was not able to execute the script. This left behind an empty browser window and an intact fortunes file.


2.4.2.   OS X

Problem:

As nw.js is designed to function the same way across platforms, we found it likely that malicious nw.js scripts that worked under Windows could be modified to run under OS X with minimal effort, as both would run under the same interpreter.

Thesis:

We wished to verify the ability to create an OS X app from our nw.js test script that would run without the need to install any other software dependencies. We then wished to find a method to prevent such programs from executing on the target computer.

OS X Apps are actually a directory structure containing files used in the application. In order to create our nw.js OS X app, we followed the following procedure:

      Open the nwjs app’s directory structure by right clicking and selecting “show package contents”
      Create the folder Contents/Resources/app.nw inside the app
      Place the index.html and package.json files in this folder
In order to mitigate the threat of NW.js apps in OS X, we tested the OS X Gatekeeper that is applied by default to programs downloaded from the Internet, and application whitelisting, using the perhaps somewhat misnamed “Parental Controls” feature in OS X. 

Finding:

Our packaged NW.js app ran successfully with only a brief flash of a blank window and successfully modified the target file. The only modifications from the Windows version were the use or forward slashes in the path, rather than backslashes and the slightly different path to the desktop folder where we placed our target file.

The OS X Gatekeeper feature was set to only allow apps downloaded from the App Store, its most restrictive setting.

When this setting is selected, OS X will refuse to open the file, as it is not from an identified developer.
 

However, if the user right clicks on the app and selects open, they will be given the option to run the app anyway. Once the user selects the option to run the file once, they will be able to run it again without a prompt or warning no matter what method they use to launch it.


If the app is modified before running, for example by adding the app.nw folder containing our test script it will show a warning that the app was downloaded from the internet and an option to open it.


Additionally, if the application in opened on one computer and copied to another, the Gatekeeper quarantine flag is not re-enabled. When we opened the NW.js app on our host MacBook, then inserted the test code before copying it onto the test VM, the app ran without a prompt in the test VM. It is also possible to clear the Gatekeeper quarantine flag from the command line by using the command “xattr -d com.apple.quarantine PATH_TO_FILE”. For these reasons, we concluded that the Gatekeeper feature is too easily subverted to provide effective protection.

The other technique we tested for OS X was to create a non-administrative user account, which in OS X is accomplished through the parental control settings. When the “Limit Applications on this Mac” option is selected, only the checked applications are allowed to run.

We confirmed that this was successful in preventing NW.js from running under the non-privileged user account.


3.            Commercial Product Demos/Research
3.1.      Invincea Advanced Endpoint Protection

Problem:

JavaScript’s typical use in malware includes obfuscated redirects to websites that employ known exploits.  This process is also known as a “drive-by-download.”  Even with security measures in place to prevent JavaScript malware from running, preventing an innocuous redirect is much more challenging.  This is because JavaScript is a core web technology, and it can no longer be disabled while still maintaining a functioning web browsing presence.  Research into Invincea Advanced Endpoint Protection is to address the problem of employing a security measure that doesn’t prevent non-malicious JavaScript from running, but stops exploits in Microsoft Windows.

Thesis:
Invincea Advanced Endpoint Protection can prevent infections of host operating systems caused from malicious JavaScript redirecting to exploit code.  This should be possible through running of the browsers in virtualized containers.  This product should be able to stop exploits outside of web browsers as well.

Findings:

Based on the information provided by Invincea and discussed below, Ransom32 and any variant of it would be considered an untrusted application in Invincea Advanced Endpoint Protection, and it would have its own virtualized container in which it would execute.  Therefore, Ransom32 would not be able to encrypt any files on the hard drive, but only in the false Windows environment that was presented from the software.  Thus, a user’s files would be safe from ransomware from Ransom32 or any other ransomware threat inside of Windows.  Further, any exploit performed through a JavaScript redirect would be contained as well.  It would be eliminated as soon as the browsing session was terminated.

Invincea is a company with a product called Advanced Endpoint Protection.  This product creates special containers that are virtualized to run any untrusted applications inside.  Invincea was contacted for a live interview and demonstration regarding Invincea Advanced Endpoint Protection.  Invincea provided YouTube demonstration videos and other product informational materials by email.  Two videos reviewed for this research are as follows:

The information provided revealed that Invincea installs a low-level kernel driver that sits in between the operating system and those applications.  That driver enforces the principle of least privilege.  If Java is compromised, it can't access resources it's not supposed.  It also creates a virtual container around those processes.  If there was a Java exploit, Invincea can collect forensic data on the attack.  The attacker only sees a basic Windows operating system.   The tool creates a barrier between the OS and applications.  The attack can't get to anything that would be considered corporate data or PII.  It would only have access to basic resources.  There is a detection capability that monitors the state of the container.  If the container does something that it doesn't normally do, it is flagged as suspicious behavior.  You can take corrective action by killing the threat, alerting the user, or refreshing the container.  Anything that was part of memory or written to disk is wiped out with the corrective action.  The user can be up and running again in about five or ten seconds.  Most security applications have to let something run on the system if they don't have a signature or something else to identify it as malicious.  Most of the time, the best case is that an alert is generated from one of these applications.

Instead of this, Invincea runs all of the untrusted applications from a container, and it's not let out of the container.  It is protecting first by default with this method.  In this situation, it doesn't matter if detection works.  Detection turns into a nice feature to enable a policy response.

Invincea Demonstration Part 1:  In this demo, a virtual machine was running Windows.  The browser was running in a container.  The container started when the user logged in.  Invincea inoculates you when you have to run older, vulnerable versions of software like Java.  The demo simulated an infection with a redirect link from an email.  The redirect started a Java exploit.  It tried to open a backdoor command prompt to indicate a backdoor shell.  Invincea identified that cmd.exe was attempting to run from the browser and it 1) killed it, 2) alerted the user, 3) enforced the restore action, which took down all of the compromised processes in the container.  It cleared the memory and any system changes.  Sitting at the kernel level, Invincea sees the process chains, and it can down those and anything in memory associated with them.  After that, there is nothing further that needs to be done to remediate the infection.

Invincea Demonstration Part 2:  This demo had the same basic setup as the first.  However, Invincea was configured in a way that is like a forensics mode.  The same exploit was launched, except this time a command prompt was opened.  Inside the command prompt, a directory listing revealed that there were no files in there because it was inside the container.  From inside the virtual desktop in the container, there were no files while there were obviously files on the desktop.  Every container is supposed to be somewhat unique since some software examines the contents of the containers to decide upon actions.  The attacker is supposed to feel like they are in a live environment to continue on with the attack.  A command prompt opened from Windows showed the directory contents of the desktop.  With this technology, you can be more concerned about forensics rather than immediately stopping the threat.  You can interact with the command prompt in the container to spoof activities.  The restore process can be manually started at any time, which kills the browser window and the command prompt window.  When this is done, the incident response data is sent back to the Invincea management center.  From inside the management console, it shows that there was a website visit, a Java launch, and a cmd.exe launch.  It further shows activities of the attacker inside the container.  The analysis tab from the management console shows the indicators of compromise.  It was able to show that an auto start was added.  It also showed that a file was written to disk and a listener was setup.  It showed Java wrote an executable and attempted to launch it.  It also showed where it was launched and the hash of it.  In this instance, only one out of fifty antivirus engines detected the event.  Invincea detected it based on behavior.  Research on one of the IP addresses revealed that it was part of a Zeus banking Trojan.  This information can be placed in your log aggregator to see if there were other systems with a similar infection )Invincea, 2015).

Invincea demonstration Part 3:  This demonstration was to show how Invincea protects users against conventional malware and file-less malware through the use of a weaponized office document.  In the demo, a website was opened which attempted to run known cryptolocker malware.  An Internet Explorer warning flashed on the screen, but it was ignored for the sake of the demo.  Invincea detected the malware running in the container, and an alert was shown in the lower right-hand corner of the system.  The demo showed that whenever the user is ready, they could click on the restore button to eradicate the malware.

Invincea Demonstration part 4:  This demo showed what happens when a user is attacked with a spear phishing email, which downloads a weaponized office document.  In the demo, a phishing email contained a link to update account settings, but instead it downloaded a weaponized Excel file.  The Excel file contained a macro, which attempted to use PowerShell to exfiltrate user's data through FTP.  If you assume the user is persuaded to open the document through social engineering, Invincea will still detect the macro trying to run because it is in the virtual container. Invincea stopped this attack.  To demonstrate that the attack failed, the directory where the FTP commands attempted to exfiltrate the data was displayed, and it was empty.  These demos showed how Invincea combines machine based learning malware detection, behavioral threat detection, and containerization to stop attacks that contain known or unknown malware.

3.2.      Bromium vSentry

Problem:

As stated above, JavaScript’s typical use in malware includes obfuscated redirects to websites that employ known exploits.  This process is also known as a “drive-by-download.”  Even with security measures in place to prevent JavaScript malware from running, preventing an innocuous redirect is much more challenging.  This is because JavaScript is a core web technology, and it can no longer be disabled while still maintaining a functioning web browsing presence.  Research into Bromium vSentry is to address the problem of employing a security measure that doesn’t prevent non-malicious JavaScript from running, but stops exploits in Microsoft Windows.

Thesis:

Bromium vSentry can prevent infections of host operating systems caused from malicious JavaScript redirecting to exploit code.  This should be possible through running of the browsers in micro virtual machines.  This product should be able to stop exploits outside of web browsers as well.

Findings:

Bromium is a company that produces a product line for application virtualization technologies on the endpoint. Their vSentry product for Microsoft Windows is an endpoint software solution in which user processes, especially Internet Explorer, run inside what is a called a micro virtual machine (micro-VM). Bromium ensures all vulnerable user tasks such as visiting a website, opening a document, or accessing a USB drive are ran inside the micro-VM. Whenever an isolated task attempts to access files, networks, devices or the clipboard, or to interact with the user, the hardware interrupts execution and passes control to the micro-VM, which applies task-specific policies. Their Live Analysis and visualization technology (LAVA) provided introspection into the operation of the micro-VM in order to provide real-time intelligence on threats when they are executed inside. Since this operates above the micro-VM, it is immune from tampering, and can provide you with threat indicators and characterization which speeds security analysts in determining the nature of threats and identifying indicators. Bromium technology is beginning to be integrated into Windows 10, and Bromium is hiring developers for the Macintosh OS X platform (Bromium, 2015).

Bromium Demonstration Part 1:  An in-person demonstration of vSentry was received, and the product functioned as described.  In Microsoft Windows 7, the demonstrator visited a site that tracked malicious web pages that served exploits.  One was identified that exploited outdated versions of Java.  With vSentry running, the demonstrator accessed the website, and it flagged that an exploit was attempting to exploit Java.  The demonstrator further explained how each tab of Internet Explorer was functioning in a Micro-VM and that the operating system was being protected from any activity inside of the browser.

Bromium Demonstration Part 2:  For the second part of the live demonstration, the demonstrator enabled Java and adjusted the settings of vSentry such that the exploit was allowed to run inside of the micro-VM.  From this demonstration, we could monitor the exploitation as it occurred, and the software captured specific events and functions of the malware.  After the Internet Explorer tab was closed, the infection was eradicated since the micro-VM was terminated.

3.3.      Spikes Security AirGap Enterprise

Problem:

As stated above, JavaScript’s typical use in malware includes obfuscated redirects to websites that employ known exploits.  This process is also known as a “drive-by-download.”  Even with security measures in place to prevent JavaScript malware from running, preventing an innocuous redirect is much more challenging.  This is because JavaScript is a core web technology, and it can no longer be disabled while still maintaining a functioning web browsing presence.  The problem addressed through researching the Spikes Security AirGap Enterprise service is attempting to employ a security measure that doesn’t prevent non-malicious JavaScript from running but stops exploits for Macintosh OS X.

Thesis:

Spikes Security AirGap Enterprise can prevent infections of host operating systems caused from malicious JavaScript redirecting to exploit code.  This should be possible through running of the browsers in virtual machine technology.  This product will only protect web browsers, and it will be incapable of exploit protection outside of a browser environment.

Findings:

Spikes Security has a product called AirGap Enterprise which takes aim to remove the security risk posed by web browsers by moving them into the cloud.  It is a browser-as-a-service model.  The easiest way to describe it is by comparing it to someone connecting to a system through a remote desktop rendering tool such as VNC or Remote Desktop and then accessing the web browser.  AirGap is a system that creates a hardware-based virtual machine session for each browsing session, and all web requests are made through this virtual machine residing in the cloud.  There is a lightweight client application that renders the browser session to the client through encrypted communications to the server.  The client has been optimized for both a high-quality video and audio experience.  Actions like copying, pasting, downloading, and printing are performed through the client and controllable through a security administration interface.  The client is available across multiple platforms, and can be deployed in Macintosh OS X environments.
AirGap offers the following types of isolation: physical, connection, session, and malware.  Physically, the hardware and the network are separated from the client, and any attack would reside on the server in the cloud.  For the connection, 256-bit encryption is used to keep the rendering of the lightweight client secure.  For the session, a hardware-isolated virtual machine is created for each browsing session and torn down when the session is closed.  For malware, if it does reach the server, it is isolated to the server without access to one’s corporate resources until the session is destroyed upon completion.
The CEO, Brandon Spikes has stated, “We believe that the architecture and isolation capabilities of AirGap Enterprise provides the most secure, least complex, and highest performance solution to the browser malware problem.”  AirGap aims to decrease deployment complexity of micro-virtualization solutions and physically remove the problem from one’s corporation (Spikes Security, 2015).




Appendix B
2016-01-09 Email Communication with Stephen Northcutt

Hello Stephen,

Upon your request and to ensure we are in alignment following our conversation, the scope of the assignment is to focus on defensive measures for ransomware written in JavaScript (Ransom32 in particular) whether it is run in an executable file with its own interpreter, inside a browser, or inside any other mechanism on Windows and Macintosh OSX systems.  We acknowledge that there currently is not a Macintosh variant in the wild nor is there a browser deployed version of the ransomware.  Further, we acknowledge that the malware may need to mature significantly to detonate effectively in a browser; however, we are still going to consider this a viable threat vector for the sake of the project.  Thus, research conducted for the Macintosh and browser variant can be simulated with a generic script.  The goal of this project is to provide research on the defensive options to counter the vulnerability to JavaScript malware and come up with a recommendation for GIAC Enterprises.

Please confirm we are on the same page.

Thank you,

Kevin Varpness
Dave Martin