Vault 7: Projects

This publication series is about specific projects related to the Vault 7 main publication.
SECRET//20350112
13 (U) Forensics
(S) This section discusses what would be discovered if a Flytrap were to undergo a
detailed forensic analysis.
13.1 (S) Likelihood of Forensic Inspection
(S) Early Cherry Blossom CONOPS placed the likelihood of forensic inspection at a
fairly low level. First, in some cases, the device is likely to be placed in a business/café
environment where little attention would be paid to the operation/behavior of the device.
Further, the devices are by and large inexpensive; so, it may be more likely for an
administrator to simply discard the device instead of undertaking a time-consuming
forensic analysis.
(S) As CONOPS expanded to other situations, it was deemed that a moderate level of
forensic protection would be required, particularly in regards to sponsor attribution.
13.2 (S) Firmware Inspection
(S) To be able to inspect a firmware image that is loaded on a device, an adversary would
need to disassemble the device, solder a JTAG header onto the board, and extract the
firmware from the flash chip through the JTAG using JTAG extraction software. The
team has been able to successfully solder a JTAG and extract the firmware from a
Linksys WRT54G.
(S) Once the firmware is extracted, it can be inspected and disassembled. Most of the
currently supported devices organize the firmware as: header(s), kernel, filesystem,
trailer(s). An adversary could extract the filesystem (typically either cramfs or squashfs),
and mount it on a linux machine. The mounted filesystem would reveal a few extra files
from the original manufacturer’s firmware, including a Mission Manager executable file,
a Copy executable file, a VPN executable file, an Autostart executable file, a shared
library, and the Generic Filter kernel module. Note that the actual names of these files
can be changed in the Image Formation process, and typically are given non-descript or
look-alike names. When each image is formed, a formal check is made on the files
inserted into the image to ensure that the files do not contain any strings that would
attribute the device to the sponsor, US intelligence organizations, or the US Government.
Furthermore, all strings are obfuscated (see 5.2.3.19) so that implant functionality is not
revealed, for example, through symbol or string analysis. Finally, suspect strings built
into the binaries (e.g., beacon addresses) are scrambled using an XOR process.
(S) The configuration portion of flash could also be extracted. If the Flytrap has already
successfully sent its Initial Beacon, the persistent Flytrap settings of 15.3 would then be
detectable, although Flytrap values are stored with non-descript or look-alike key names,
and the key values (e.g., beacon addresses) are scrambled using an XOR process.
13.3 (S) Gaining a Shell
(S) Early firmware versions of the Linksys WRT54G (and other devices) had security
holes that allowed a telnet daemon to be placed and executed on the device, giving shell
124
SECRET//20350112