# Vault 7: Projects

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

### Dark Matter

# Triton v1.3

- 1
- 2
- 3
- 4

# - empty directories are not shown in collected output
watchpaths:/some/remote path:/another remote/path:/yet another path/.txt:~/a/relative/path
# BIGFILE: chunk/download the specified file, respecting exfil window
bigfile:/some/file/to/chunk.dat
# DROPBOX: chunk/download and remove files from this folder, respecting exfil window
dropbox:/some/remote/path
UPDATING THE IMPLANT
Run the new implant builder's "create" command to generate patched.brains.disk and
patched.brains.nvram files
•
Run the old implant builder's "update" command, be sure to choose the correct update
file for the installation:
specify patched.brains.disk with -b to update a Triton instance♦
specify patched.brains.nvram with -b to update a Der Starke instance♦
specify the old implant's target.cert and ca_key with -c and -p, respectively♦
•
Run the old implant builder to issue a "put" command that places the update here:
/var/spool/uucpd/ufcp
•
Each time the implant reloads, it will attempt to load an update in
/var/spool/uucpd/ufcp
A Der Starke instance will reload approximately every 10 minutes♦
A Triton instance will reload every time it beacons♦
•
After post-processing new files from the implant, verify that the latest
guids/guid.XXX file is different from previous versions
•
BEACON SEQUENCE
The implant will only beacon if the following conditions are met:
The implant has been triggered at least once♦
The hibernation period and one interval has expired since the first trigger♦
The implant has not attempted to beacon for at least one interval♦
The implant can successfully make an HTTP GET request to one of the check URLs♦
•
The implant makes an HTTP(S) GET request to the LP and downloads a the a, i, c and s
files from the LP, if any are present
•
The implant decrypts, decompresses, then executes the payload
If no a, i, c, or s files were present on the LP, the payload is considered
invalid
♦
If the payload was valid, the beacon will be considered successful, resetting
the internal error count
♦
•
The implant compresses and encrypts resulting collection•
The implant compresses and encrypts some state information for itself•
The implant uploads the collection and state information back to the LP with a single
HTTP(S) POST
•
The LP saves the uploaded data into the fls folder and optionally creates an "s" file
from the state information provided. This state information will be available for the
implant to download upon subsequent beacons
•
Other factors:
If an implant hasn't had a successful beacon in 3 months, it will perform a
forced beacon the next time it's triggered. During a forced beacon a check URL
is not consulted before contacting the LP
♦
The implant will uninstall on its 4th consecutive failed forced beacon. With
regular triggering, this happens after approximately 12 months. Without regular
triggering, it may take longer
♦
•
POST PROCESSING
Run postproc.pz -h, for instructions. The following files/folders will be created in the
specified output directory:
dir_listings/............dirwalk task results, named by processing date•
bundles/.................bundle task output, named by processing date•
scripts/.................script task output, named by processing date•
files/...................get, bigfile and watchpaths files. Completed files suffixed
with modification date timestamp
•
dropbox/.................dropbox files. Completed files suffixed with modification
date timestamp
•
tasks/task.log.XXX.......a log of completed tasks for the beacon, suffixed by
postproccessing date
•
guids/guid.XXX...........GUID of the implant that uploaded the results, suffixed by
postprocessing date
•
SECRET//NOFORN

- 1
- 2
- 3
- 4