Simply install box-js from npm:
Looking to use box-js with Cuckoo? Use
cuckoo-package.pyas an analysis package.
Let’s say you have a sample called
sample.js: to analyze it, simply run
Chances are you will also want to download any payloads; use the flag
--download to enable downloading. Otherwise, the engine will simulate a 404 error, so that the script will be tricked into thinking the distribution site is down and contacting any fallback sites.
Box.js will emulate a Windows JScript environment, print a summary of the emulation to the console, and create a folder called
sample.js.results (if it already exists, it will create
sample.js.1.results and so on). This folder will contain:
analysis.log, a log of the analysis as it was printed on screen;
- a series of files identified by UUIDs;
urls.json, a list of URLs contacted;
active_urls.json, a list of URLs that seem to drop active malware;
resources.json, the ADODB streams (i.e. the files that the script wrote to disk) with file types and hashes;
IOC.json, a list of behaviours identified as IOCs (Indicators of Compromise). These include registry accesses, written files, HTTP requests and so on.
You can analyze these by yourself, or you can automatically submit them to Malwr, VirusTotal or a Cuckoo sandbox: for more information, run
For further isolation, it is recommended to run the analysis in a temporary Docker container. Consult
integrations/README.md for more information.
If you wish to automate the analysis, you can use the return codes – documented in
integrations/README.md– to distinguish between different types of errors.
While box.js is typically used on single files, it can also run batch analyses. You can simply pass a list of files or folders to analyse:
By default box.js will process samples in parallel, running one analysis per core. You can use a different setting by specifying a value for
--threads: in particular, 0 will remove the limit, making box-js spawn as many analysis threads as possible and resulting in very fast analysis but possibly overloading the system (note that analyses are usually CPU-bound, not RAM-bound).
You can use
--loglevel=warn to silence analysis-related messages and only display progress info.
After the analysis is finished, you can extract the active URLs like this:
Analyzing the output
The first source of information is the console output. On a succesful analysis, it will typically print something like this:
In this case, we are seeing a dropper that downloads a file from
http://foo.bar/baz, setting the HTTP header
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0). Then, it proceeds to decode it, and write the result to disk (a PE32 executable). Finally, it runs some command in the Windows shell.
sample.js.results/a0af1253-597c-4eed-9e8f-5b633ff5f66awill contain the payload as it was downloaded from http://foo.bar/baz;
sample.js.results/f8df7228-7e0a-4241-9dae-c4e1664dc5d8will contain the actual payload (PE executable);
sample.js.results/d241e130-346f-4c0c-a698-f925dbd68f0cwill contain the command that was run in the Windows shell.
Every HTTP request is both printed on the terminal and logged in
urls.json. Duplicate URLs aren’t inserted (i.e. requesting the same URL twice will result in only one line in
active_urls.json contains the list of URLs that eventually resulted in an executable payload. This file is the most interesting, if you’re looking to take down distribution sites.
snippets.json contains every piece of code that
resources.json contains every file written to disk by the sample. For instance, if the application tried to save
Hello world! to
$PATH/foo.txt, the content of
resources.json would be:
resources.json file is also important: watch out for any executable resource (eg. with
"type": "PE32 executable (GUI) Intel 80386, for MS Windows").
Some scripts in the wild have been observed to use
new Date().getYear() where
new Date().getFullYear(). If a sample isn’t showing any suspicious behaviour, watch out for
If you run into .JSE files, compile the decoder and run it like this:
The error will typically look like this (line numbers may be different):
You can see that the exception was raised in
Proxy.ActiveXObject, which looks like this:
Add a new
case "winhttp.winhttprequest.5.1" (note the lowercase!), and have it return an ES6
Proxy object (eg.
ProxiedWinHttpRequest). This is used to catch unimplemented features as soon as they’re requested by the malicious sample:
Rerun the analysis: it will fail again, telling you what exactly was not implemented.
WinHttpRequest.open as needed:
and iterate until the code emulates without errors.
@CapacitorSet: Main developer
- npm packaging
- command-line help
- support for non-UTF8 encodings
- bug reporting
- advice on integrating UglifyJS in box-js
- improving the features of UglifyJS used in deobfuscation