box-js v1.9.15 releases: A tool for studying JavaScript malware


A utility to analyze malicious JavaScript.


Simply install box-js from npm:

npm install box-js --global


Looking to use box-js with Cuckoo? Use as an analysis package.

Let’s say you have a sample called sample.js: to analyze it, simply run

box-js sample.js

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 the screen;
  • a series of files identified by UUIDs;
  • snippets.json, a list of pieces of code executed by the sample (JavaScript, shell commands, etc.);
  • 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 behaviors 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 box-export –help.

For further isolation, it is recommended to run the analysis in a temporary Docker container. Consult integrations/ for more information.

If you wish to automate the analysis, you can use the return codes – documented in integrations/ – to distinguish between different types of errors.

Batch usage

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 analyze:

box-js sample1.js sample2.js /var/data/mySamples ...

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:

cat ./*.results/active_urls.json | sort | uniq


NAME                   DESCRIPTION                                                                     
-h, --help             Show the help text and quit                                                     
-v, --version          Show the package version and quit                                               
--license              Show the license and quit                                                       
--debug                Die when an emulation error occurs, even in "batch mode", and pass on the exit  
--loglevel             Logging level (debug, verbose, info, warning, error - default "info")           
--threads              When running in batch mode, how many analyses to run at the same time (0 =      
                       unlimited, default: as many as the number of CPU cores)                         
--download             Actually download the payloads                                                  
--encoding             Encoding of the input sample (will be automatically detected by default)        
--timeout              The script will timeout after this many seconds (default 10)                    
--output-dir           The location on disk to write the results files and folders to (defaults to the 
                       current directory)                                                              
--preprocess           Preprocess the original source code (makes reverse engineering easier, but takes
                       a few seconds)                                                                  
--unsafe-preprocess    More aggressive preprocessing. Often results in better code, but can break on   
                       some edge cases (eg. redefining prototypes)                                     
--no-kill              Do not kill the application when runtime errors occur                           
--no-echo              When the script prints data, do not print it to the console                     
--no-rewrite           Do not rewrite the source code at all, other than for `@cc_on` support          
--no-catch-rewrite     Do not rewrite try..catch clauses to make the exception global-scoped           
--no-cc_on-rewrite     Do not rewrite `/*@cc_on <...>@*/` to `<...>`                                   
--no-eval-rewrite      Do not rewrite `eval` so that its argument is rewritten                         
--no-file-exists       Return `false` for Scripting.FileSystemObject.FileExists(x)                     
--no-folder-exists     Return `false` for Scripting.FileSystemObject.FileExists(x)                     
--function-rewrite     Rewrite function calls in order to catch eval calls                             
--no-rewrite-prototype Do not rewrite expressions like `function A.prototype.B()` as `A.prototype.B =  
--no-hoist-prototype   Do not hoist expressions like `function A.prototype.B()` (implied by            
--no-shell-error       Do not throw a fake error when executing `WScriptShell.Run` (it throws a fake   
                       error by default to pretend that the distribution sites are down, so that the   
                       script will attempt to poll every site)                                         
--no-typeof-rewrite    Do not rewrite `typeof` (e.g. `typeof ActiveXObject`, which must return         
                       'unknown' in the JScript standard and not 'object')                             
--proxy                [experimental] Use the specified proxy for downloads. This is not relevant if   
                       the --download flag is not present.                                             
--windows-xp           Emulate Windows XP (influences the value of environment variables)              
--dangerous-vm         Use the `vm` module, rather than `vm2`. This sandbox can be broken, so **don't  
                       use this** unless you're 100% sure of what you're doing. Helps with debugging by
                       giving correct stack traces.  

Copyright (c) 2016 CapacitorSet


Anastasis Vasileiadis

PC Technical || Penetration Tester || Ethical Hacker || Cyber Security Expert || Cyber Security Analyst || Information Security Researcher || Malware analyst || Malware Investigator || Reverse Engineering

SC ProDefence SRL - Cyber Security Services