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

2048-bit public/private RSA keys•
RSA key exchange•
AES-256 symmetric key encryption•
Cryptovariable generation using PolarSSL's built-in number generator•
Digital signatures that rely on SHA-512.•
In particular, all data exfiltrated to the LP are encrypted and signed using these
algorithms. The keys used to decrypt the data (in particular, the CA's private key) reside
only on the high-side. Hence, any would-be eavesdropper cannot decrypt the data, even if he
gains full control of the LP. Furthermore, each file is encrypted with a separate symmetric
key.
See the Aeris-specific cryptographic documentation (Appendix) for more information.
POST PROCESSING
To decrypt collected data files, the user must move them from the LP to a high-side system.
Once this is accomplished, he can use the Aeris post-processor (postproc.py) to decrypt.
Each file will adhere to the following naming convention by default: {timestamp}- {random
six-character suffix}.pkg, where the timestamp represents the UNIX time at which the file
was uploaded to the LP. We recommend that the operator not change file names during
retrieval, since the file name itself helps to establish when the file was received and
serves as a basis for file naming conventions within the decrypted data store. However, the
post-processor does not depend on this particular naming convention.
Post-processor usage is described in detail via the builder's -h option and will not be
rehashed here. Once the post-processor has processed each file, it will create (or add to)
the following directory structure:
DATASTORE_{target ID}/: top-level datastore for target {target ID}
exec/: data captures from foreground exec commands♦
files: collected files♦
results/: high-level status/result summary for each task♦
file_data.bin: dictionary of SHA-512 checksums for partial files (if known)♦
•
Within exec and results, files are named according to the input file name. The files
directory mimics the file system on the target box. So that multiple versions of a file can
be supported, each file has its time of last modification appended to its name. Note that
since the implant is unaware of time zones, the timestamp will reflect the target's local
time. Also, if the file is still in transit, the file name will also include a â.partâ
extension. Once the entire file has been received and if its SHA-512 checksum matches that
of the file on the target system, the .part extension will be removed. A hypothetical file
repository might appear as follows:
DATASTORE_5555/
files/
home/
user/
myfile.1346598270•
⋅
bigfile.134607928.part⋅
file1.1346070577⋅
file1.1346086895⋅
◊
♦
•
In each case, the relative path from the files directory reflects the path of the file on
the target system; the timestamp reflects the time of last modification on the target
system; and the .part extension reveals some state of incompleteness. Also note that we have
two versions of file1, one that was last modified at 1346070577 (27Aug2012 at 12:29:37) and
one at 1346086895 (27Aug2012 at 17:01:35).
A file may remain with a .part extension permanently if one of the following conditions
holds:
If one or more sections of the file were lost or corrupted in transit;1.
If a target-side error was encountered when trying to exfiltrate (read or copy) part
of the file;
2.
If the file was modified during exfiltration (and therefore the checksum on target
differs from that on the high-side). In such instances, recovering a current, valid
copy of the file may or may not require further action on the part of the operator. If
the file is part of a watch directory, the implant will detect any file changes and
will exfiltrate it at a later time. If the file's retrieval was triggered via a GET
command, the operator should reissue that command.
3.
SECRET//NOFORN

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