# Vault 7: Projects

This publication series is about specific projects related to the Vault 7 main publication.

### Imperial

# Aeris -- Users Guide

- 1
- 2
- 3
- 4
- 5
…
- 8
- 9

CONTROLLING AERIS
INVOKING AERIS
./aeris &•
./aeris -e &•
./aeris -f &•
(Aside: Note that the use of the name aeris is notional here; the operator can name the
binary anything that he wishes, per section III.A).
The '-e' and '-f' flags have to do with enforcing singleton instances. By default, Aeris
will check for other instances of itself when it starts. If it finds such an instance, it
will exit. Since this behavior is not always desirable, the '-e' and '-f' options provide
the capability to bypass these checks as follows.
'-e': If this option is specified, the new instance of Aeris will wait until the
previous instance of Aeris has exited
•
'-f': When this option is specified, the new instance of Aeris will ignore any other
instances of Aeris. This is not recommended in general, because two simultaneous
running instances may overwrite each other's on-disk configuration
•
There is one extenuating circumstance in which using the '-f' flag may be useful. If the
implant exits uncleanly (e.g., via a kill -9), the semaphore used to synchronize multiple
instances may persist. In this case, a new Aeris instance may believe that another one is
running when that is not the case. Specifying '-f' will enable the newer process to
circumvent this issue.
COMMANDING AERIS
The Tasker (task_builder.py) generates the command packages used to command an Aeris
instance. It also provides the operator with a custom command line interface for creating
command files. (The Collide Handler provides a very similar user interface for task
generation. See Section VII.A for more information.)
The operator must provide the Tasker with the implant's receipt.xml file, so that the
tasking will be encrypted appropriately. Thus, the Tasker may be invoked as follows:
# python task_builder.py receipt.xml
Once the tasker is running, follow the on-screen instructions.
Aeris allows operators to combine multiple commands into batches that are uploaded to the LP
and eventually processed as a unit by an Aeris instance. Up to 65535 commands are allowed in
a single batch. Batches are created using the âgenerate batchâ sub-shell of the Tasker.
In generate_batch mode, there are special commands to modify command order, remove commands,
cancel generate_batch mode, and finally, once all tasks have been added, generate a bundled
task (i.e., a command file). Once a task bundle is generated from the standalone Tasker, the
operator should upload it to the listening post and copy it to the directory
/var/www/{static implant ID}/update.pkg. (See section III.C for more information on implant
identifiers.)
Tasks within a task bundle are executed in sequence. If a task fails, the remaining tasks
are not run. The results of the tasks are returned in one result file.
To see how a specific command works or what its parameters are while running the Tasker,
simply type 'help {command}', where {command} is the command in question. For example,
typing:
# help exec_fg
will cause the Tasker to display help information on the execute foreground command.
One final note regarding tasking: The implant will not execute any residual, persistent
tasks if no task is present on the LP. This means, for example, that if the operator has
previously set a watch path or a drop box, file data will not be exfiltrated without a task
present on the LP. For that reason, it is recommended that the operator configure an
innocuous âdefaultâ task (such as setting the beacon interval but not changing its
value) unless he wants the implant to remain silent.
SECRET//NOFORN

- 1
- 2
- 3
- 4
- 5
…
- 8
- 9