Adobe: JSX and JSXBIN files

I wrote about older Adobe scripting before. I recently discovered that Adobe products support scripting using so-called ExtendScript language with code being stored either in a source-level JSX file, or its binary equivalent – JSXBIN (it’s actually considered legacy at this stage). Add these file extensions to your watch list.

The documentation [PDF warning] suggests that some security precautions are in place, and:

1.5 Activating full scripting features
The default is for scripts to not be allowed to write files or send or receive communication over a network. To allow
scripts to write files and communicate over a network, choose Edit > Preferences > General (Windows) or After Effects Preferences > General (Mac OS), and select the Allow Scripts To Write Files And Access Network option.
Any After Effects script that contains an error preventing it from being completed generates an error message from the application. This error message includes information about the nature of the error and the line of the script on which it occurred. The ExtendScript Toolkit (ESTK) debugger can open automatically when the application encounters a script error. This feature is disabled by default so that casual users do not encounter it. To activate this feature, choose Preferences > General, and select Enable JavaScript Debugger

I don’t have access to Adobe products, but these seem to be interesting features.

Defenders should look for:

  • unusual processes spawn by Adobe products
  • invocations of afterfx.exe – scrutinize its command line
  • on macOS: use of AppleScript to invoke DoScript
  • presence/invocation of autostart scripts in Adobe’s Startup and Shutdown folders (the exact location is unknown to me; if you have Adobe products, please let me know and I will update this post)

1.6.5 Running scripts automatically during application startup or shutdown
Within the Scripts folder are two folders called Startup and Shutdown. After Effects runs scripts in these folders
automatically, in alphabetical order, on starting and quitting, respectively

Yes, it’s not a lot to pivot from, but if you have an access to a large number of systems, you may want to keep an eye on process trees spawn around Adobe products. Just to be ahead of time.

Other info:

Not installing the installers, part 2

In the last post I described how we can pull some interesting metadata from decompiled installers. Today I want to discuss one practical example of how this data can enrich analysis, both manual and automatic (f.ex. sandbox, EDR).

Many programs cannot be properly analyzed by sandboxes, because they require command line arguments. While command line options for native Windows OS binaries are usually well documented (well, not really, there is a lot of undocumented stuff, but let’s forget about it for a second), command line options used by goodware is a completely different story. And of course, even worse for malware.

The good news about goodware is that they handle command line arguments in a very predictable way. The string comparisons are usually ‘naive’, direct and not optimized, and often, the programs include actual help that can be seen after running the program with the /?, /help, -h, –help arguments. And very often, a search for ‘usage’ keyword inside the binary can help us to find the options that program recognizes. f.ex. this is what we see inside cscript.exe:

Predictable is good, and can serve at least a few purposes:

  • we can generate a list of known parameter strings that goodware typically uses (and even attribute it to specific software vendors)
  • we can create yara signatures for these
  • we can incorporate this set into EDR command line parsing routines to assess invocation’s similarity to known good
  • we can also leverage this to run the sample in a sandbox or manually with these easily discovered command line arguments (kinda like assisted fuzzing)
  • we can include these findings in the report itself to hint analysts they may need to do some manual reversing (it would seem the program accepts the following command line arguments…)

Looking for typical command line arguments is actually quite difficult. There are a lot of ways to implement string comparisons and as I explained long time ago in one of my sandbox series, there are like gazillion different string functions out there. Plus different compilers, different optimizations make the code even harder to comprehend. Naive search for /[a-zA-Z_0-9]_/ could work on a binary level, but this is going to hit a lot of FPs. Decompiled scripts can come to the rescue, as they include actual invocations of programs and specify precisely what parameters will be passed to the program.

The attached list focuses on a basic command line argument extraction (just the /foo part) from around 10K decompiled scripts. More advanced analysis would include options taking parameters (f.ex. /foo bar).

You can download it from here.