gscript: Scriptable dynamic runtime execution of malware
gscript
Genesis Scripting Engine
Genesis Scripting (gscript for short) is a technology I’ve developed to enable more intelligent malware stagers. Typically, stagers are pretty dumb. Most stagers are unique to the malware they deploy and do not allow for “bundling” of multiple payloads. Sophisticated attackers do in fact bundle their payloads, which makes runtime uncertainty even more assured.
GScript changes that. GScript allows for dynamic execution logic per payload. This is achieved by a modified Javascript runtime that is statically embedded in the final stager binary. This runtime/virtual machine runs “hook” functions that you’ve defined in your script, checking to ensure the script wishes to proceed after each hook.
This has significant benefits over traditional tactics:
- Scripts are far more “sandboxed” from each other. If you’re bundling 10 payloads and 1 of them has a syntax error in its script, with gscript, only that scripts VM dies, not the entire program.
- GScript’s VM, while sandboxed, has native hooks injected into it. This allows the VM to interact with things outside of the VM (filesystem, network, registry, etc.).
- These functions are by and large, completely cross-platform. This allows someone to only learn GScript to write scripts without having to learn a different programming language.
- Execution is also parallelized using the very effective go routine paradigm, resulting in the much faster execution of stagers with multiple payloads.
This development process is incredibly efficient with our gscript CLI utility.
The VM’s custom runtime (Engine) is referred commonly as “GSE” – Genesis Scripting Engine.
Architecture
Compiler
The compiler is what translates your gscripts and their assets into a finalized binary. Some features of the compiler:
- Support native binary compilation for all major operating systems: Windows, Linux, OS X
- Can support large numbers of scripts and assets into a single executable.
- Built-in lossless compression and obfuscation of both scripts and embedded assets.
- VERY FAST. Compilation times generally less than 5 seconds.
- Post compilation obfuscation to remove references to the library.
- Defaults to a null logger for the final binary (no output ever!), but can be overridden to inject a development logger into the final binary for testing.
VM Engine
The final binary contains the gscript engine with all scripts and their imported assets. It will initialize VMs, one for each script, and execute them generally in parallel (there’s priority overrides, but more on that below!).
The VMs cannot interact with one another and errors in one VM will be gracefully handled by the engine. This prohibits one VM from causing instability or fatal errors preventing other scripts from executing.
The Engine has been designed to be lean and free from bloated imports. It’s come a long way, but there will be more improvements here in the future as well.
Execution Flow
The VM expects your scripts to implement three functions (called “hooks” in our documentation):
BeforeDeploy()
– intended to function as the reconnaissance function to determine if the script should attempt to deploy it’s second stage.Deploy()
– contains the stage two deployment logic.AfterDeploy()
– allows the script to clean up after a successful deployment.
If any of these functions returns false
, the engine will prevent subsequent execution of the functions proceeding for that script.
When either hooks return false or all hooks run successfully, the VM will destroy itself and notify the scheduling engine that the VM is finished executing.
Installation
$ go get github.com/gen0cide/gscript/cmd/gscript
Usage
Copyright (C) gen0cide
Source: https://github.com/gen0cide/