# Vault 7: Projects

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

### Imperial

# Aeris -- Users Guide

- 1
- 2
…
- 5
- 6
- 7
- 8
- 9

STAND-ALONE LP CONFIGURATION
The standalone CGI option allows the user to deploy a single CGI binary (agnt.cgi-32 or
agnt.cgi-64) together with the LP-specific files on an Apache web server. In general, the
Apache configuration mimics that used to support other OS X implants, such as BowmanHeir and
Triton. The operator will need to configure Apache with support for SSL, mutual
authentication, and SNI (server name indication). The LP configuration script contains all
of the required, LP-specific information (keys and vHost files). See Section II regarding
use of this script.
To use the CGI-enabled LP, the operator should place the appropriate CGI binary (32 or 64
bit) in the implant's document root. The CGI program must be named âagnt.cgiâ, as this
URL will be requested when an Aeris instance attempts to post data back to the LP. Note that
the CGI script does not handle tasking, as these packages are generated by the Aeris tasker,
and the implant fetches them directly with an HTTPS GET. Thus, it handles HTTPS POSTs only
and acts as a pass-through, writing any posted data directly to a file on the LP. A summary
of expected naming conventions (within the implant's document root) follows.
agnt.cgi: CGI script that handles HTTPS POST requests. Note: it must be named
agnt.cgi. The provided files, agnt.cgi-32 and agnt.cgi-64 must be renamed.
•
update.pkg: Tasking payload (encrypted), generated by the Aeris builder and fetched
directly by the implant
•
fls/: Results directory (the CGI program will write each exfiltrated payload to this
directory using the {timestamp}-{six-character suffix}.pkg naming convention)
•
Note that we have provided source code for the CGI program in addition to statically-
compiled 32 and 64 bit binaries so that the operators can modify the CGI program if needed.
When deploying a tasking payload, the operator should copy the file directly to the
implant's document root directory on the LP (e.g., /var/www/{implant_id}) and name the file
update.pkg.
POSTFIX/SMTP LP CONFIGURATION
Aeris includes a tarball that contains a patched and pre-built version of Postfix-2.10.0
that is suitable for use on Ubuntu 12 Server. You can also build your own version of Postfix
and cyrus-sasl using the scripts provided in postifx/build. Please see the README file in
that directory for guidance on building a custom Postfix server.
Once Postfix is deployed, it must be configured to accept mail and provide tasking: - The
payload should be placed in /var/spool/.emlrcpt - Edit /etc/aliases so that e-mail for the
implant's ID is forwarded somewhere useful, then run newaliases - Run saslpasswd2 -c -u
localhost , and enter the password, as shown in the implant receipt to allow the implant to
authenticate with Postfix
APPENDIX
A. REPLICATING AN EXISTING AERIS INSTANCE
The Aeris distribution includes a capability (patcher.py) that enables an operator to
recreate an existing Aeris instance. To do this, run the patcher as follows:
# ./patcher.py {path to unpatched binary} {config file (generated during initial build)}
{desired on-target config file name} {output (patched binary) path}
As the name suggests, patcher modifies the specified unpatched Aeris binary (see Section I)
by adding in both the encrypted configuration and the on-disk config file name and writing
the result to the specified output path. By providing the config file and and its on-target
name for a previously-deployed binary, the operator can reconstitute the binary that was
deployed on the corresponding target.
Aside: Technically, the patcher will not create a pure byte-for-byte replica of an existing
deployment, as it always inserts some random data after the configuration during the
patching process. However, as this random data is ignored during execution, the binary is,
for all intents and purposes, a byte-for-byte replica. For this reason, we say that the
patcher yields a functional replica of an existing deployment.
B. GENERATING A NEW LP
We have also included a capability (mklp.py) that allows the operator to create a new
listening post for a previously-deployed Aeris instance. (Note that the builder generates
files for all LPs specified when building a new instance.) Use mklp as follows:
SECRET//NOFORN

- 1
- 2
…
- 5
- 6
- 7
- 8
- 9