WikiLeaks - Vault 7: Projects

# Vault 7: Projects

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

### Hive

# Users Guide

9 November, 2015

- 1
- 2
…
- 6
- 7
- 8
- 9
- 10
…
- 30
- 31

SECRET//NOFORN
(U) Hive 2.9.1 User's Guide (U) Pre-Deployment
2 (U) Pre-Deployment
(S) Before initial deployment, Loki's Blot/Swindle must be set-up with Hive's Tool ID (0x65ae82c7) to
proxy connections to the Honeycomb tool handler. Honeycomb can reside on the same server as
Swindle but it is strongly recommended that it be deployed on a different server. Honeycomb acts
much like a traditional iterative server that handles incoming beacon connections one-by-one. After
the implant is validated by Swindle, the implant traffic is re-routed directly to Honeycomb.
Honeycomb then establishes an encrypted session with the implant. Swindle continues to proxy the
encrypted network packets.
2.1 (S) Proxy
(S) Loki documentation covers the procedures for setting up a Blot DP/LP with the Blot/Swindle
proxy, as such procedures are beyond the scope of this document. Hive provides a sample Swindle
configuration file (swindle.cfg) to be saved to /etc/blot on the Swindle server. Restarting
Swindle (service swindle restart) will re-read the configuration file. The Hive project made no
changes to the Swindle binaries or server and aims to fully conform to the existing Swindle
protocols and procedures. In the Swindle configuration file, the most important parameters are the
IP and port for the tool handler (e.g. Honeycomb) and the Hive Tool ID.
2.2 (S) Tool Handler
(S) Honeycomb is a server application that handles the beacons proxied from Swindle. The
Honeycomb server can be configured to start the tool handler automatically at system start (via the
/etc/init.d or /etc/rc.local scripts).
(S) Honeycomb accepts the following command line options:
python2 honeycomb.py [-p <port>] [-f <file path>] [-l <log path>]
where:
<port> is the port that honeycomb will listen on for proxy connections coming from
Swindle.
<file path> is the location where beacon rsi files will be written.
<log path> is the location where beacon log files will be written.
(S) Upon receiving a beacon, Honeycomb will parse-out the MAC address, public IP address, and
uptime of the implanted box. Honeycomb will then write out a ".rsi" file that is one-way transferred
for ingestion into Ripper Snapper. The implant ID used in the Ripper Snapper files is the
unformatted MAC address of the implanted box. As of Hive 2.0 additional survey data are collected
from the beacon. Additional information on this data can be found in section 3.1.
(S) Hive v2.0 functionality was added to Honeycomb so that it will keep a basic log of beacons that
are received. Every beacon will have a log entry created that contains a timestamp of when the
beacon was received, the MAC address, public IP address, and the version of the implant that
beaconed. In addition, for Hive v2.0 beacons and later, there will be a flag related to which OS the
beacon came from.
2.3 (S) Patcher
(S) While the Hive implant can be installed in a target and executed with the desired parameters, a
binary patched with parameters tailored for the designated target is typically produced using the
patcher to provide greater operational control. The resulting binary is a file with a name ending with
in the string PATCHED in the current working directory from where the patcher is executed – hived-
mikrotik-ppc-PATCHED for example. Be aware that Hive implants created with the patcher will ignore
SECRET//NOFORN//20401109 3

- 1
- 2
…
- 6
- 7
- 8
- 9
- 10
…
- 30
- 31