Vault7: CIA Hacking Tools Revealed
Navigation: » Latest version
Owner: User #3375506
User #? Developer Guide
Note: This page is under development.
Overview
User #? is a software tool used to build custom installers for target computers running Microsoft Windows operating systems.
Concept of Operations
An operator uses User #? to build a custom installation executable, execute that installation executable on a target computer, and (optionally) decode the results of that execution.
Build
An operator uses the User #? builder to construct a custom installation executable.
The operator configures an installation executable to install one or more payloads using a variety of techniques. Each payload installer is built from individually configured components that implement part of the installation procedure.
The operator may designate that installation is contingent on the evaluation of the target environment. Target conditions are described using a custom rule language.
The operator may configure the tool to output a log file during execution for later exfiltration.
Execute
An operator runs the installation executable on a target computer running a Microsoft Windows operating system. The installation executable should be loaded into and executed solely within memory.
The operator is responsible for selecting the appropriate method for gaining on-target execution for the configured User #? tool.
If the executable has output a log file, the operator collects it from the filesystem for later analysis.
Decode
An operator decodes the runtime-generated log file to evaluate detailed execution results.
The execution log stores result codes from each installer component and facts evaluated as part of the target environment validation process.
Referenced Documents
User #? complies with the following specifications:
NOD Persistent DLLDynamic Link Library v1
The User #? executable DLLDynamic Link Library is compliant with the NODNetwork Operations Division Persistent specification version 1. It can be safely loaded and executed in process memory.
In-memory Code Execution (ICEIn-memory Code Execution) v3
The User #? executable ICE-DLL is compliant with the In-memory Code Execution (ICEIn-memory Code Execution) specification version 3. It can be loaded as a module by an ICE-compliant loader using the ‘Fire’ execution mode.
System Design
User #? Composition
A User #? executable contains one or more installers. An installer is a stack of one or more installer components. User #? invokes each component of the stack in series to operate on a payload. The ultimate purpose of an installer is to persist a payload.
User #? will optionally evaluate rules to determine whether to execute an installation. Rules may be set on each installer and/or globally.
Executables
User #? executables contain and run one or more installers on a target system.
An executable may have a global rule that will be evaluated before execution of any installers. If a global rule is provided and evaluates to false the executable aborts operation.
Executables may be constructed for both x86 and x64 architectures and in the following formats:
DLL |
Microsoft Dynamic-Link Library - Compliant with NODNetwork Operations Division Persistence Specification v1 - Executes in a thread created in the DLLDynamic Link Library entry point (DllMain) - Memory-loadable (compliant with NODNetwork Operations Division Persistence v1) |
ICE DLL |
ICEv3 Module - Compliant with In-memory Code Execution (ICEIn-memory Code Execution) Specification v3 - Supports ‘Fire’ feature set |
If no rules need to be evaluated by the executable, User #? uses an alternate executable, called a Cricket. A Cricket is equivalent to a User #?, but has been stripped of the rule processing engine.
Installers
Installers encapsulate the process used to install a payload on a target system. Installers are constructed from one or more components that each contribute to the installation process.
Installers run by passing a payload through each member of the component stack. An installer may invoke a component at run time or build time, depending on payload availability and the components’ execution time requirements. Installers are biased toward build-time execution of components to minimize on-target activity.
An installer may have a rule that will be evaluated before execution. If an installer rule is provided and evaluates to false the associated installer is skipped.
Components
Components form the functional portion of installers. Components may be used to introduce payloads to the installer stack, modify a payload on the stack, install a payload on a target, etc.
User #? users configure components individually before using them to construct installers. Components may be used in multiple installers.
Components may be developed by third-parties and added to an existing User #? build system.
Payloads
Payloads are the software tools that an installer is meant to persist on a target. Payloads are passed through each component on the installer stack.
Payloads are typed by format (EXE, DLL, SYS, PIC), architecture (x86, x64), and optional arguments and interface. The output type of a component must match exactly the input type of the next component on the stack.
User #? includes a built-in payload component which is used to introduce a payload to the component stack.
Rules
Rules are statements that describe on-target conditions required for the successful operation of an installer or a User #? executable as a whole. Rules use boolean operators to combine simple facts into complex expressions.
Logic
For any given executable, including some number of installers built from some sequence of components, User #? will operate according to the following logic.
Build Time
At build time, User #? will validate the executable and run the build time components.
Validation
For each installer in an executable, User #? evaluates the payload exchanges between the constituent components. User #? ensures that both the payload types and availabilities between each component are compatible.
Build Time Components
Some components are designed to operate on a payload at build time. For each installer in the executable, User #? will invoke the components to operate on the payload until the first run time component is reached. The output of the last build time component will be the input of the first run time component.
Run Time
At run time, User #? will evaluate the target environment and run the run time components.
Global Rule
An executable may be configured with a global rule that describes conditions that are required for the executable as a whole. Before executing any components, User #? will evaluate this global rule.
If the global rule does not evaluate to “true”, the User #? aborts operation.
Installer Rules
For each installer in the executable, a rule may be configured that describe required conditions for that particular installer. Before executing any of an installer’s run time components, User #? will evaluate its installer rule.
If the installer rule does not evaluate to “true”, the User #? skips that installer.
Run Time Components
For each installer in the executable, User #? invokes each run time component to operate on the payload. If any component fails, User #? will unwind, calling the components in reverse order to undo whatever actions they had taken.
Components
C