# Vault 7: Projects

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

### Hive

# Developers Guide

15 October, 2014

- 1
- 2
…
- 8
- 9
- 10
- 11
- 12
…
- 14
- 15

SECRET//NOFORN
Self-Delete Hive Engineering Development Guide
3 Self-Delete
3.1 Description
Self-delete is used to insure 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 .log 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.)
3.2 Discrepancy Report and Analysis
Discrepancy report DR-00134-2012 was issued after Operations determined that Hive version 2.5 was
self-deleting prematurely. Analysis showed that a calculation involving the current time and the file
modification time used to determine the time since last contact could result in a negative number that
was then cast from an integer to an unsigned long integer. This resulted in a large positive number that
exceeded the delete delay and subsequently caused Hive to self-delete.
3.3 System Clock Issue
Further analysis of this issue revealed that determining when to self-delete Hive can be problematic due
to the inability to accurately assess the reliability of the host's system clock. Here are three possible
operational scenarios, others may exist.
1. The host has a system clock that resets to epoch time upon reboot. The decision to self-delete
can only be determined by examining the time since last reboot and the time since last contact.
The time since last contact need not be kept in non-volatile memory, as it is meaningless without
a stable system clock. If the device is connected to an unstable power supply which is frequently
interrupted, then Hive might never be deleted.
2. The host has a system clock that maintains the time across reboots and may or may not be
synchronized to an NTP server. Self-deletion can be determined by comparing the time of last
contact (maintained via the last modified time of the configuration file) with the current time. If a
system administrator changes the time significantly from when Hive was first installed and
executed, then this action could cause Hive to self-delete.
3. The host has a system clock that resets to epoch time upon reboot, but is synchronized to an
NTP server at some point after reboot. The self-delete decision for this possibility is similar to
that of scenario 2 During a short period after reboot the system clock is near epoch time, so no
determination can be made until the clock is set.
4 SECRET//NOFORN//20391015

- 1
- 2
…
- 8
- 9
- 10
- 11
- 12
…
- 14
- 15