# 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
- 6
…
- 8
- 9

DEPLOYING TASKS
To deploy the tasking payload, refer to section VII.
UPDATING AERIS
Aeris does not have an explicit update function as other implants might. To update Aeris,
one needs to send a series of commands in a batch task: 1. Delete the old
(currently-executing binary) using an exec_fg command (note that using exec_bg leads to a
race condition between deleting the binary and the put command); 2. Put the new binary in
the same location as the old binary (making sure to set the permissions so that the new
binary is executable); 3. Issue a hard_reset command.
UNINSTALLING AERIS
Aeris will uninstall in any of the following three cases:
The operator issues an uninstall command;1.
The operator has configured a self-delete timeout. If the implant has not beaconed
successfully within the specified number of seconds, it will self-terminate;
2.
The operator has configured an uninstall date. Once the date is reached, the implant
will uninstall.
3.
The implant will take the following steps when uninstalling:
It will delete all pending task files (i.e., these are not uploaded);1.
It will delete its config file;2.
If the operator has configured a DNS domain, the implant will query that domain; 4. It
will delete itself;
3.
It will exit the process.4.
In each case, the implant will attempt to first overwrite the file with data from /dev/
urandom prior to deleting the file. However, âsecureâ deletion is not a given; on
Solaris, for example, overwriting the implant binary with pseudo-random data will result the
implant's crashing due to an invalid instruction. In any case, the files are deleted.
The implant also allows the operator to specify additional files to purge when issuing an
uninstall command. This feature can be used, for example, to clean up any external
persistence mechanisms.
COMMUNICATIONS
All communications between implant and endpoint occurs via HTTPS. Each implant instance has
a unique certificate authority (CA). The implant's certificate as well as each LP
certificate is signed by the CA. When establishing a communications channel with an LP, the
implant and the LP verify each other's certificates against the CA. If the certificates do
not validate, the connection is terminated. In addition, if the server certificate is
invalid, the implant will demote the LP (i.e., cycle to the next LP in the list and use it
for the next beacon, provided that multiple LPs were configured). Other conditions causing a
demotion include an inability to connect when the implant has Internet access and a failure
to decrypt or validate a tasking payload.
Two sets of communications occur during the course of a beacon cycle. First, the implant
will issue an HTTPS GET to download the tasking payload. Once this payload has been
validated and decrypted, and once the contents of the package have been executed, the
implant will issue an HTTP POST to upload the collected data. Important URLs on the LP are
listed below.
/update.pkg
This URL should allow the implant to access an encrypted tasking payload.♦
If no package exists and the client receives a 404, it will not take any action
for the present beacon cycle. The LP will not be demoted in this case.
♦
•
/agnt.cgi
This is the URL to which the implant will upload collected data. See Section VII
of this document for more information.
♦
•
Once data files have been uploaded, the user must copy the files from the LP to a high- side
system in order for decryption to occur.
CRYPTOGRAPHY
Aeris uses a cryptographic suite that is compatible with the NOD Cryptographic Specification
(NSPEC-001). Specifically, the following algorithms are used:
SECRET//NOFORN

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