Kaspersky Releases an Open Source Digital Forensics Tool
Bitscout initially started as a hobby project a few years ago (version 1.0 was never released to the public), and it has been continually improved based on the requirements that arose in Kaspersky investigations involving digital forensics.
Bitscout 2.0 enables forensic investigators to remotely analyze a system, and allow the system’s owner to monitor the expert’s activities and ensure that their access is limited to the targeted disks.
The owner of the system on which forensic analysis will be conducted simply must boot the system from a CD/USBDongle provided by the investigator, allowing the analyst to connect remotely to Bitscout over SSH using a VPN.
Bitscout includes several popular tools designed for forensic analysis and uses a text-based user interface in order to make it easy to operate:
Bitscout relies on 3 roles in the process of remote forensics:
1. The Owner
The owner is a user who has physical access to the target system and owns it.
The owner’s role is to download, verify and burn Live ISO image file to a
removable storage. After that the target system must be started from this
bootable media. In case of LAN DHCP network configuration everything shall
work automatically. In case of other setup, the owner has to configure
network access using management utility that is available on the Live system
(starts automatically on the TTY1 on boot).
2. The Expert
The expert is a remote user that connects to the target system over SSH using
VPN link through the expert’s server. Bitscout shall be built with VPN server
certificates, configuration and SSH keys placed on the disk image.
3. Expert’s Server
The expert’s server shall be located in the internet and is used to run a VPN
server as well as chat server for communication.
a. You build your own Live disk instead of using someone else’s. The build
process is straightforward and verbose. There is no place for mistrust, given
that the OS repositories are trusted.
b. Live disk image is built using bash scripts only and standard Ubuntu tools
and packages, making it both transparent and customizable for all.
c. Owner can monitor what is going on in expert’s container. It’s possible to
attach and monitor changes in the expert’s container as root.
2. Forensically sound
a. We have tested that Bitscout doesn’t modify hard drive data or other storage media attached to the system. This is essential base for forensic operations.
b. Bitscout contains most popular tools to acquire and analyze harddrive disk images on site.
c. The owner of the system has to manually authorize which disk devices to be accessible by the expert in read-only (or read-write) mode.
d. While running as root the expert cannot modify or reset access to the provided devices, which prevents potential data loss from the source disk.
a. The set of tools available on Bitscout can be easily customized by editing respective text files in the script directory before building. You can add standard packages or your own tools to it. Make it available to expert, system owner or both.
b. Both system owner and expert can install additional software packages on already running system. All changes will be done indepently (expert can’t change owner’s environment) and only in memory.
c. If certain operations require more memory or large disk which is not available on the system, the owner may attach writable external storage device (such as fast USB flash memory) to be used for storage or swap.
a. Bitscout project is designed to be minimal yet universal tool to access remote storage device. It contains minimal set of packages, libraries and tools to start the system and provide most common forensic tools to the expert immediately. Certain optimizations yet to be added to reduce size even further. All suggestions and contributions are welcome!
b. The system uses no graphical interface on purpose. This reduces disk image size and used RAM.
c. The expert’s environment runs as unprivileged LXC container, which saves from overhead of full virtualization. The container relies on the same kernel as the host system.
d. The container spawns from overlayed source rootfs. This allows to avoid duplication of system binaries and configuration. Yet, mapped with copy-on-write access it provides almost unlimited modification of the whole OS. The real limit is just the size of available memory and swap.
As a matter of fact fully running OS with a child OS inside the container used less than 32Mb of RAM in our tests.