SANS ISC: Investigation of BitTorrent Sync (v.2.0) as a P2P Cloud Service (Part 3 ? Physical Memory artefacts)

• SANS Site Network
  • Current Site
  • SANS Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

[This is third guest diary by Dr. Ali Dehghantanha. You can find his first diary here and second here. If you would like to propose a guest diary, please let us know]

Continuing my earlier posts on investigation of BitTorrent Sync version 2.0, this post explains remaining artefacts of user activities in physical memory of Windows 8.1, Mac OS X Mavericks 10.9.5, and Ubuntu 14.04.1 LTS related to BitTorrent Sync version 2.0. 
Analysis of the running processes using the ‘pslist’ function of Volatility was able to recover the process name associated with the BitTorrent Sync client application (e.g., ‘BitTorrent Sync.exe’ for Windows OS, ‘BitTorrent Sync’ for Linux OS, and ‘BitTorrent Sync’ for Mac OS), which included the process identifier (PID), parent process identifiers (PPID) as well as the process initiation time; Examinations of the network details using the ‘netscan’ or ‘netstat’ function of Volatility determined that the network and socket information such as the transportation protocols used, local and remote IP addresses (including the IP addresses of the peer discovery methods used and the peer nodes), socket states, as well as the timestamp information could be recovered from the RAM (see Figure 1).

Figure 1: An excerpt of BitTorrent Sync network information recovered using the ‘netscan’ function of Volatility. 

Undertaking data carving of the RAM captures and swap files determined that only the images used by the client application and synced files could be recovered. However, a search for the term ‘btsync’ or ‘bittorrent sync’ was able to recover the complete text of the log and metadata files of forensic interest (e.g., sync.log, sync.dat, history.dat, and settings.dat) in the RAM in plain text. In cases when the original file has been deleted, a Yarascan search for the text from the remnants could help attribute the remnants to the BitTorrent Sync or other processes of relevance to identify its origin. Figure 2 illustrates an occurrence of history.dat in the memory space of ‘BitTorrent Sync.exe’ of the Windows 8.1 VM investigated. 

Figure 2: Copy of history.dat file recovered from the memory space of ‘BitTorrent Sync.exe’.

Username (login email) and password for the Linux client application’s web GUI can be detected following the strings ‘username=’ and ‘nwpwd=’ in the RAM respectively. These appeared to be remnants from the form input field of the Linux client application’s web GUI; an example is shown in Figure 3. In addition, we also located several password hits in the similar fragments containing the login email in the memory space of BitTorrent Sync.  In a real life scenario, this could potentially provide the practitioner the opportunity to extrapolate the login password from the non-dictionary or alphanumeric terms surrounding the email string in the memory space of BitTorrent Sync.

Figure 3: Username and password recovered from the RAM of Ubuntu OS.

The next post will illustrate Windows Thumbnail Cache, Registry, Prefetch Files, and Link Files artefacts of BitTorrent v2.