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
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
Direct Research
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
●
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
